I have a repo started with the Blues Stack and it keeps on failing at CI time when reading the supposedly set environment variable DATABASE_URL as seen on the image.
checklist:
I have checked that the DATABASE_URL on production and staging Fly.io apps has a value. I checked this using the Secrets section on each app page
I have set a fresh FLY_API_TOKEN just yesterday on the Repository secrets section on Github
I have attached Remix apps to the Postgres DB apps successfully. This is how the DATABASE_URL secrets that you see in the image, were set. When I say it in plural it’s set both for the production and staging apps
I confirm that I have in both production and staging apps, the secrets DATABASE_URL + SESSION_SECRET required for Remix
I finally managed to fix this by putting: ENV DATABASE_URL="postgres:myapp:HASHYPASS@top2....my-app-server-db.internal:5432/myapp into my Dockerfile, AT LINE 28!
Specifically after the line: FROM ${BUILDER_IMAGE} as builder
(and before the RUN apt-get... line)
Placing it just before FROM $BUILDER... results in a different failure “Error failed to fetch an image or build from source: error building: failed to solve with frontend dockerfile.v0: failed to create LLB definition: no build stage in current context”
Placing it at the end of the Dockerfile also had no effect!! (So this took my a fair long while to debug and was a fairly significant painpoint in my new adoption of fly. See also my other comments on elixir images being missing.)
It seems kinda like the first deploy somehow works but then it gets off the rails. (I’m hoping with this fix and keeping a close eye on things in git maybe it’ll get easier on future tries.) but then on subsequent tries something isn’t set properly (the DATABASE_URL, I suppose, but maybe since it’s getting created on the first pass of an app it gets piped in after creation instead of while building the image).
Other things I tried, in reverse chronological order as best as I remember:
Delete the worker (I had been doing fly deploy --remote-only sometimes, so it seemed like the worker didn’t have the secret…probably not going down the right path)
Remove DATABASE_URL from app secret and do a new fly postgres attach (this just resulted in a new secret URL, no actual change to compile error)
DATABASE_URL in Dockerfile ENV at the bottom of the file (definitely didn’t work)
Following the syntax of ENV ECTO_IPV6 true (no = sign, not sure if this matters or not to docker)
Setting env val locally on dev machine (no impact)
Previously I deleted my app/db entirely and redeployed and that seemed to work (but I’m kinda forgetting, it seems like it somehow changed my app name from appshortname-server to appfullname, I’m sure this was me, but it left the short name version around, which had all my certs on it, so my domain name forwarding broke when I did all that, and just updating my DNS on the name server hasn’t resolved it, I will now try to fix that with fly certs which is currently empty probably due to the rename/deletion)
Perhaps some other things
Anyway, sorry to reply to a “solved” thread, but I hope this can get somebody unblocked in an “easier” way in the future.
Side hint:
If you’re following the advice to set the DATABASE_URL in your docker file but didn’t note down what it is, but it is set on your app originally, do this to recover it safely: $> fly ssh console $> echo $DATABASE_URL
That’s the string you want to put in your Dockerfile ENV DATABASE_URL=<string>
