Update: the error happens when I use the CLI on MacOS. Works fine on Linux. Applies whether I login or use a token, or whether I deploy in detached mode. CLI on MacOS does not upload the right content to deploy.

Is this supposed to happen, or is there a way to deploy from MacOS?

Are you sure you are running railway up in the correct folder?

Yes, I'm sure -- especially since, as I said, doing the exact same thing on Linux works correctly.

Is your project on our mac on an external drive?

What version of the CLI are you using?

No, on the main drive -- and I've actually attempted it on two different Macs, one Intel and one Apple Silicon, with the same results. I'm using version 3.12.1.

What version of macos?

14.6.1

Do you see the same behavior with all projects?

Haven't attempted with another project.

Let me know how that goes please.

Same problem: I ran the commands below and got the exact same output, with a failure to build nixpaks and empty app directory contents.

 3030  railway init -n experimental-railway-project
 3036  rails new experimental-railway-project
 3038  cd experimental-railway-project
 3049  rails server # check that it will run locally
 # Here I created an empty service manually in the web portal
 3054  railway link
 3058  railway status # check link
 3067  railway up

Link to the failed build here:

https://railway.app/project/6bef699c-92ad-4e60-8dd7-34ebdbe4d127/service/d3690d57-2582-4635-bef7-e456f6ea2ce4?id=662f1654-359e-4039-bf99-8e1f39c0d2f2

Meanwhile on Linux:

rails new experimental-railway-project
cd experimental-railway-project
railway link
> Select a project experimental-railway-project
> Select an environment production
> Select a service stellar-elegance
alpine-vm:~/work/experimental-railway-project$ railway up
  Indexed
  Compressed [====================] 100%
  Uploaded                                                                                                                            Build Logs: https://railway.app/project/6bef699c-92ad-4e60-8dd7-34ebdbe4d127/service/d3690d57-2582-4635-bef7-e456f6ea2ce4?id=3bd49367-6cb5-4cf6-91bc-f07711de964e&

[Region: us-west1]
=========================
Using Detected Dockerfile
=========================

context: 9906c44c2d0de246b13d86b81e12085e
#0 building with "default" instance using docker driver

{{ FURTHER OUTPUT TRUNCATED }}

Now, that plain project didn't actually deploy because I didn't setup the variables for the production environment, but it did upload and build, which the attempt on the Mac hadn't.

Hmmm, not really sure what to tell you here, this seems like it's an issue with macos.

Update 2: It's something specifically with my setup. I ran a deploy through a GitHub action on a MacOS runner, and it succeeded (deployment ID `df668386-7b61-42a5-922e-bc8a0e383db0`)

Mystery solved!

This is indeed due to my setup (though it's not that unusual). I keep a git repo in my home directory to manage various config files, and since I don't want to put everything into that repo, I only explicitly add specific files using the -f flag, and I have this:

√  work git:(personal) cat ~/.gitignore
*
√  work git:(personal)

I use an alternate file to actually manage the global ignores, and set that in .gitconfig.

Now it makes sense. Railway looked up what to ignore via .gitignore , but rather than using just the project's own .gitignore, it used the combination of that plus the system's -- which says to ignore everything! So it did.

When I renamed that global .gitignore file, railway up ran correctly.

Should I file an issue on the project's GitHub? Intuitively, this behavior seems incorrect to me -- when uploading the project, a tool like Railway should consider the project's own .gitignore, but not the system's global one, which likely has nothing to do with the project and may for some parameters be overridden by it.

I'm glad you figured it out but this wouldn't be an issue with the CLI itself so there wouldn't be anything we can do, it would be an issue with WalkBuilder - https://docs.rs/ignore/latest/ignore/struct.WalkBuilder.html

And looks like someone already has the same issue - https://github.com/BurntSushi/ripgrep/issues/1394

Not quite. Since `WalkBuilder` is part of the ripgrep project , I've downloaded ripgrep, and here's what I found:

backend git:(railway) rg controller
config/initializers/wrap_parameters.rb
7:ActiveSupport.on_load(:action_controller) do

config/application.rb
8:require 'action_controller/railtie'

config/environments/test.rb
23:  config.action_controller.perform_caching = false
29:  config.action_controller.allow_forgery_protection = false

config/environments/development.rb
17:    config.action_controller.perform_caching = true
24:    config.action_controller.perform_caching = false

config/environments/production.rb
15:  config.action_controller.perform_caching = true
27:  # config.action_controller.asset_host = 'http://assets.example.com'

app/controllers/authentication_controller.rb
1:# app/controllers/authentication_controller.rb
√  backend git:(railway) cd ~
√  ~ git:(personal) rg controller
rg: No files were searched, which means ripgrep probably applied a filter you didn't expect.
Running with --debug will show why files are being skipped.
✗  ~ git:(personal)

So yes, it will (possibly incorrectly) read in the ~/.gitignore file when there's no alternative, even though it's not the actual ignore file used by git, but when run from within a directory with its own .gitignore, it'll only use that.

Does the railway CLI switch to the home directory internally before attempting to upload?

Not that I can tell -

https://github.com/railwayapp/cli/blob/master/src/commands/up.rs

Is there a way to get the contents of the uploaded directory for a successful build, the way I've been getting printouts for failed ones? If it includes .bundle, log, node_modules, etc. we'll know that the .gitignore file the CLI tool used was the (for that build, nonexistent) global one rather than the one inside the project.