I’m deploying an existing Rails app, I have an entirely fresh Fly organisation. fly launch works fine. fly deploy fails on the assets:precomplie step.
Obviously, this is a common enough problem that it’s mentioned in the Getting Started Guide
I have my rails master key in the correct config file, and the error output even links to the file. fly launch successfully created the RAILS_MASTER_KEY secret and I’ve confirmed that the key is correct.
Console Output:
=> [build 5/6] RUN bundle exec bootsnap precompile app/ lib/ 1.6s
=> ERROR [build 6/6] RUN SECRET_KEY_BASE=DUMMY ./bin/rails assets:precompile 3.4s
------
> [build 6/6] RUN SECRET_KEY_BASE=DUMMY ./bin/rails assets:precompile:
#16 3.370 Missing encryption key to decrypt file with. Ask your team for your master key and write it to /rails/config/master.key or put it in the ENV['RAILS_MASTER_KEY'].
------
Error failed to fetch an image or build from source: error building: executor failed running [/bin/sh -c SECRET_KEY_BASE=DUMMY ./bin/rails assets:precompile]: exit code: 1
That all being said, I don’t know why any credentials should be required during the build step. Any suggestions on how to avoid this for a “stock” rails setup?
This error is being reported to honeybadger, and the API key for honeybadger is stored in the credentials file. So access to the credentials is definitely possible.
Yeah, when you defer the build, it runs the compilation step during a time when secrets are available, which is why it’s being reported to Honey Badger. The only recommend deferring the build for troubleshooting, then switching back to running the compilation when secrets aren’t available.
If you are evaluating Fly.io for the first time there may be some value in setting precompile to defer initially for evaluation and then work over time to eliminate the issues that prevent you from running this step at build time. Once those issues are resolved, regenerate your Dockerfile using the following command:
As far as I can tell, the build step shouldn’t need the master key. I know there are further improvements coming to this in 7.1 - @rubys has been hard at work (which is super exciting).
I’ve tried the backport approach suggested by DHH here but that didn’t seem to have any effect.
Arianf’s suggestion in the same thread also didn’t work.
I’ve just confirmed, after deleting dockerfiles and rerunning
$ rails g dockerfile
$ fly deploy
I get this error.
------
> [build 6/6] RUN SECRET_KEY_BASE=DUMMY ./bin/rails assets:precompile:
#16 1.807 Missing encryption key to decrypt file with. Ask your team for your master key and write it to /rails/config/master.key or put it in the ENV['RAILS_MASTER_KEY'].
------
Error failed to fetch an image or build from source: error building: executor failed running [/bin/sh -c SECRET_KEY_BASE=DUMMY ./bin/rails assets:precompile]: exit code: 1
It looks as though my setup still needs the master key at build time.
I’ve progressed to the “Different Error” stage by adding the RAILS_MASTER_KEY as an env var. ENV RAILS_MASTER_KEY="$(cat config/master.key)"
I’m not certain if this is progression or regression but I now get the same error with some extra output and this error in Honeybadger
Let’s try a vanilla application. You can run through the steps shown in the Getting Started guide. If it helps, I’ve condensed the important steps to the following:
rails new list; cd list; bin/rails generate scaffold Name name; fly launch; fly deploy
Feel free to accept all of the defaults, this app doesn’t need postgres or redis.
This app deploys for me, and I assume it will deploy for you. If not, something really weird is going on. If it does work for you, then something in your config is accessing a credential, and for some reason the stack traceback produced here isn’t being helpful.
After a bit of trial and error with a vanilla application, deploys work with cssbundling-rails but fail with sassc-rails (which we’re currently using) and dartsass-rails (which we’re going to upgrade to at some point).
The only way I can get the build to work with sassc-rails or dartsass-rails is by passing the master key as a build arg.
Probably worth noting that we’re using propshaft and importmaps, but they don’t appear to cause the failure.
Your manually passing RAILS_MASTER_KEY got me past it and now onto other issues (like yarn missing despite being installed in the generated Dockerfile, but that’s for another day—edit: it’s because it’s in another stage, but asset precompilation with jsbundling-rails requires yarn, so keeping the executable around is needed).
If require_master_key is set to true in production.rb like this:
config.require_master_key = true
then setting dummy value like this:
RUN SECRET_KEY_BASE=DUMMY
won’t do anything. Rails will still go looking for a real key and will error out.
Comment from DHH:
“Yeah, I don’t think we want to make a liar about of that config. If you have a setup where you don’t want to inject the master key during build (and use dummy key base), then you need to turn that off.”
Based on that comment I turned off require_master_key and now precompile works without a real key: config.require_master_key = false