I was exploring how to automate wasp-lang/wasp deployments to Railway with Wasp's CLI (we already have it for Fly and we want to support Railway next). I believe I have stumbled upon a bug in the Railway CLI in the railway up command.

How to reproduce it

Some context: Wasp apps are full-stack apps that you compile into a Node.js server app and a React client app in different folders. You can think of deploying Wasp apps as deploying three Railway services: client, server and the database. So when we want to deploy the e.g. server app, we deploy it from the server folder.

What I did to deploy the server app:

1. Init the project with railway init --name "my-app" in the project root dir
2. Build the Wasp app
3. Go into the server app folder cd .wasp/build
4. Create a new server app service with railway add --service "my-app-server" --variables "PORT=8080" ...
5. Try to deploy the server app service with railway up $(pwd) --service "my-app-server" --no-gitignore --detach

The deployment fails with some Nixpacks related error which is strange because we have a Dockerfile in the .wasp/build folder. I was curious and I wanted to find out what's going on, so I've built the CLI from source and added some debug logs.

Building from source and debugging

When I added logs in the src/commands/up.rs to see which kind of paths are being included in the zip I got output similar to this:

.wasp/build/Dockerfile
.wasp/build/server.js
...

I did not expect the zip to include the folder structure like that, I thought my dir will be zipped as if it's the root dir.
I expected the zip to look like this:

./Dockerfile
./server.js
...

I guess that's the reason why Dockerfile was not picked up by Railway - it's not in the root of the zip. That didn't seem right, so I explored some more.

Possible bug

Inspecting the src/commands/up.rs a bit more, I found out that there were two paths being used in the command function:

// First path
let prefix: PathBuf = configs.get_closest_linked_project_directory()?.into();

// Second path
let path = match args.path {
    Some(path) => path,
    None => prefix.clone(),
};

• prefix is the dir of the project
• path is either provided via args (as I do in my example above) or the same as prefix.

I found that the up command walks the path dir tree and finds all the files to add to the zip but uses prefix to strip the first part of the file path:

let mut builder = WalkBuilder::new(path);
...
let stripped = PathBuf::from(".").join(path.strip_prefix(&prefix)?);
archive.append_path_with_name(path, stripped)?;

For example:

• if the project dir is /root/dev/project -> prefix is /root/dev/project
• if we provide the path arg as /root/dev/project/.wasp/build -> path is /root/dev/project/.wasp/build
• when we want to zip the /root/dev/project/.wasp/build/Dockerfile -> we only strip the project dir and we end up with .wasp/build/Dockerfile

Possible solution

I'm a Rust newbie, but I tried playing around and came up with this change:

// If args.path is provided - use it, otherwise use the linked project dir 
let project_files_path = match args.path {
    Some(path) => path,
    None => configs.get_closest_linked_project_directory()?.into(),
};

The change:

1. merges the path and prefix concepts into a single variable project_files_path
2. uses the project_files_path in both places

I've tested it out with my use case and it fixes the issue I had.

Let me know if this all sounds okay to you and I can submit a PR (I have the commit ready to go: infomiho@f7bcce1)