We just enabled the new deploy github hook and it appears to identify our project as an Elixir project and complains about the version of Elixir. Does this deployment pipe not use the Dockerfile for building?
We get the following error during preparation
No preset version installed for command mix
Please install a version by running one of the following:
asdf install elixir 1.17.3-otp-27
or add one of the following versions in your config file at /usr/src/app/.tool-versions
.....
Howdy!
It might be an issue with out deployer image but mind if I ask a one thing just so we can better debug this?
Was the app previously launched on Fly.io already and you now added a GH repo connection via UI or was it launched via UI?
It was an existing app that deployed via github CI and the flyctl. I connected the app to the existing repo yes.
Hi, quick update. I was able to reproduce and I’m baking some improvements into our phoenix launcher that will address that issue, thanks for reaching out! Just wanted to let you know that sooner than later.
We shipped an update that should understand .tool-versions from Phoenix projects. Can you try again?
That being said we still need to do more work on the UX for launch UI from apps launched from flyctl.
Out of curiosity why would it need to know about the tool-versions file? Shouldn’t the entire setup for a deploy be driven my the dockerfile?
Our current issue while trying to deploy is lack of secrets being shared with our Dockerfile, they are listed when we do flyctl secrets list but the deploy fails with the secret missing.
Also of note, github is reporting our deployments from “production” when this is in fact a staging setup.
Deployment to production by fly-io[bot]
This is scary and should maybe report the fly app name instead!
The reason that phoenix takes precedence in our launcher is because we check that the app has releases setup and create these files as needed. In the order of the framework scanners Phoenix comes before the Dockerfile one. This is something I’m particularly interested in revisiting at some point to be honest!
As for your secrets in Dockerfile. Fly.io secrets are runtime only and Dockerfile envs are compile time. To add secret things there you should use build arguments. Here’s some tips from previous conversations in our community forum:
Thanks for the feedback, we will add that to our backlog.
As for your secrets in Dockerfile. Fly.io secrets are runtime only and Dockerfile envs are compile time.
This is tough, we have some hard requirements for secrets during build that probably won’t disappear anytime soon.
Example: some library dependancies, Oban Pro, require authentication to fetch.
I know exactly the feeling. To help with that and also make it easier for devs to onboard here our phoenix monolith has Oban pro vendored and that went quite nice for us.
That doesn’t exclude build args with secrets being important, we want to have a solution for that eventually but I can promise it’s on anyone’s roadmap at the moment on our launch UI.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.