You can instrument to log into shell and printenv to see if the vars are set as approp prior to the step resulting in exec failure.
Also, vars set with Fly secrets will override env set with fly.toml. A word of caution: At runtime, even though secrets are set in env vars, they aren’t quite the same thing.
It’s my first deployment. It’s a Rails 2.7 app with a few initializers to set up a Zoom API, Sentry, Skylight, etc.). Unfortunately, the zoom API library I use won’t allow the deployment to move on and raises an exception when running bundle exec rails assets:precompile
ssh won’t work since there is no VM to login into.
You could printenv (runtime secrets) in the dockerfile with CMD, I guess. Anywho…
Is the bundle exec... step a build step? If so, as pointed out by @fideloper-fly, you may need to set build-time secrets to configure the Zoom API (regular Fly secrets are runtime-only).
@jsierles is the resident RoR expert. Tagging them, just in case…
Ah, I literally just posted a similar issue myself. Build-time vs runtime-only… Interesting, coming from Heroku, env vars are one and the same and are used throughout the whole flow/process.
I came here to find the same thing. My issues are being caused by not have env variables available at build time. Having to pass in the pile of secrets is going to be fun. Will have to do some research.
Feels a little off to me. Not sure it’s going to allow for a very seamless deployment flow like we had on Heroku - they really nailed it on that front…
I have a LOT of apps to port over and need to find the right solution that’ll require as minimal fettling as possible per deployment.
I think I understand the issue. According to Build Secrets · Fly Docs I need to mount a secret into my Dockerfile using the RUN command. But my docker knowledge is almost zero, and I don’t know where that command comes from.
You can run --build-arg ENV_VAR1=${ENV_VAR1} to set build time environment variables. If you’re doing deploys from GitHub Actions or another CI, it should be reasonably straightforward to script something up that passes a whole bunch all at once.
We designed the secrets this way intentionally. Admittedly, we didn’t expect Heroku to drive away their users, or we’d have done some work to make this part smooth.
I tried fly deploy with --build-arg and --build-secret with sed -e '$ ! s/$/,/g' .env.fly | tr -d '\n' that mainly gets my .env.fly and joins with comma. But no luck.
Across 150+ Heroku apps, each with 20-30 secrets… that’s a lot of manual work and I won’t be able to port to Fly just yet.
Granted, the Heroku announcement was only a few days ago and you’re on the back foot to help us all out. Think you’ll be able to accomodate us all with a smoothly migration flow in the coming weeks? I think we have until the end of November to migrate!
@pama - while doable, it doesn’t seem practical unless we can use the fly secrets as the source.
In Heroku, the env vars are the single source of truth for the production app (or staging/pr-review apps). Having to deploy with these same vars or have them elsewhere (e.g. GitHub actions) will quickly let things drop out of sync.
Hopefully I’m mistaken, but at this stage it seems the deployment process is going to be a lot more involved than what Heroku devs are used to.
@rubys that seems a good tip and I was able to move on and see that the server variables are there when performing the rails migration, however, it failed when running the server command. Maybe because the way I built the command: