Fly worked when launched from my workstation because Docker was copying a .env file. Once the .env file was added to the .dockerignore list, it stopped working. Thus the current issue is still not being able to load env variables.
It sounds like the build process inside your Dockerfile doesnât have access to the env variables.
The build process inside my Dockerfil does not have access to the DATABASE_URL from fly.io, but this build process is working correctly without it. Itâs only breaking once it reaches the release step, outside the scope of the Dockerfile. It was not breaking earlier because it had access to a .env file copied by mistake to the application code from my local repository.
The release step also does not have access to the env variables, which is odd because following the docs, it should have access to it.
what if you piped the DATABASE_URL env to your dockerfile, eg -e DATABASE_URL=... and then add it to the release_command: release_command = "DATABASE_URL=<url> bunx turbo run --filter @diet-it/db db:deploy"
Itâs feels wrong to do it in order to âfixâ the behavior that was expected from the machine but what else can I do? I think I will give it a try. Thank you.
I would phrase that slightly differently⌠at least one of the secrets are missing or different than the ones specified in your .env file.
Try running fly console.
From there, you can run the release command directly and watch it fail. One by one set environment variables as they are in your .env. Once it works, update the associated secret to match.
You are correct, the DATABASE_URL is indeed present on the machine. I didnât think of running the failing command on a normal machine because I thought they were only run on ephemeral machine, but since these ephemeral machines are an exact copy of the deployed ones, it makes sense.
I did discover that the env variable is indeed present with
echo $DATABASE_URL
postgres://...
And running the release_command bunx turbo run --filter @diet-it/db db:deploy manually results on the same error. I managed to reproduce the issue locally.
This leads me to think Prisma is at fault.
At leas now I have something Iâm better at debugging.
Thank you guys.
Sorry for dragging this so long just to find out it was not a fly.io issue. And thank you for your help debugging it. I will proceed to make a PR fixing this on prisma if I can.
I appreciate your help a lot.
2 Likes
Are you married to Prisma? Maybe itâs time to start seeing other ORMs.
More then 1 year of development on top of it unfortunately. I just finished migrating to a monorepo and the issue only happens on monorepos apparently.
Donât fall for sunk cost fallacy. The cons of Prisma is that itâs inefficient at querying, eg it has to do separate DB calls to join relations.
I know it does some dumb stuff. We have a lot of raw dog sql commands for anything more complex then basic crud. but I canât see a a way we could migrate out of prisma without delaying the delivery of this project. It already have a release date and a waitlist.
If we find a better alternative, it will not be our choice for future projects.
For anyone curious how I finally solved this:
[deploy]
release_command = "echo \"DATABASE_URL=\\\"$DATABASE_URL\\\"\" > ./packages/db/.env && bunx turbo run --filter @diet-it/db db:deploy"
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.