LukasKnuth
Bake release version at compiletime
I’m using the standard Dockerfile generated by mix phx.gen.release --docker with a small change:
# Compile the release
ARG APP_VERSION
RUN mix compile
The added ARG expression accepts a Docker build-arg that I supply when building the image:
docker build . -t my_app --build-arg APP_VERSION=0.1.1
In my mix.exs I load the data from the Environment variable:
defmodule MyApp.MixProject do
use Mix.Project
def project do
[ #Other config
version: version()
]
end
def version do
System.get_env("APP_VERSION", "0.0.0-local")
end
end
I’m expecting that MyApp.MixProject.version/0 is invoked at compile time and that the ENV variable is read then and “baked” into the final release.
This seems to be true partially:
- during image build it logs:
assembling my_app-0.1.1 on MIX_ENV=prod - running
bin/my_app versionreturns the expected0.1.1 - the file
releases/start_erl.datacontains15.2.1 0.1.1(the later is the version) - the folder in
releases/0.1.1exists
All this seems to indicate that it worked fine, but at runtime, i get the fallback value:
iex> Application.spec(:my_app, :vsn)
~c"0.0.0-local"
I can’t figure out why it seems to work everywhere except for the Application spec.
I have also tried setting the APP_VERSION env variable to some other string to see if it might be evaluated at runtime - it still returns "0.0.0-local". What am I overlooking?
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance










First 4 of 4 Posts
arcanemachine
Off the top of my head, I would try this:
build arg != environment variable
EDIT: On second thought, maybe just skip the build arg part altogether and pass it as an environment variable:
docker build . -t my_app -e APP_VERSION=0.1.1Then, I don’t think you would need to put anything in the Dockerfile.
LostKobrakai
Not sure if that’s helpful, but all the places where things worked are the result of
mix release, whileApplication.specuses the.appfile of the compiled application as created bymix compile. The.appfile would be inlib/my_app-{version}/ebin/my_app.appof the release.LukasKnuth
Bingo! Even the folder is called
lib/my_app-0.0.0-local/. I have moved theARG APP_VERSIONinstruction higher in the Dockerfile, just belowENV MIX_ENV="prod"and now everything works as expected!I wonder what step really creates the
.appfile, because I had the instruction right abovemix compilebefore (where it didn’t work). After moving it, the following commands now also receive it:mix deps.getmix deps.compilemix assets.deployNone of which seems like an obvious candidate to me.
rhcarvalho
One of those might be doing it as a side effect of their transitive dependencies. You don’t have to call “mix compile” exclusively to trigger compilation (and in that case your
RUN mix compileline was likely a no-op.)For example, it happens all the time when you run
mix test– code is first compiled, then the test suite is run.