gcauchon
Docker build started failing - unchecked dependencies for environment prod
I’ve been working on many projects based on Phoenix in the last few years and worked on the transition from mix phx.server (for production environment) to OTP release with distillery then mix release. Starting last night, for a reason I can not explain, splitting mix deps.get and mix compile on different docker intermediate layers does not work anymore :
COPY mix.* ./
RUN mix deps.get --only ${MIX_ENV}
COPY . .
RUN mix compile
And fails with the following errors:
Unchecked dependencies for environment prod:
* parse_trans (Hex package)
lock mismatch: the dependency is out of date. To fetch locked version run "mix deps.get"
* mimerl (Hex package)
lock mismatch: the dependency is out of date. To fetch locked version run "mix deps.get"
…
* phoenix_ecto (Hex package)
lock mismatch: the dependency is out of date. To fetch locked version run "mix deps.get"
** (Mix) Can't continue due to errors on dependencies
The command '/bin/sh -c mix compile' returned a non-zero code: 1
Moving RUN mix deps.get after COPY . . works, but it defies the caching purposes of isolating dependencies… I tried on both MacOS and Ubuntu 18.04 with the same result ![]()
We have been using this setup for as long as I can remember for every ruby/node/elixir projects we are packaging as Docker images. Take a look at the elixir-boilerplate project we are maintaining to start every web projects at Mirego.
Marked As Solved
ericmj
It’s an internal manifest to Hex we write to deps/$DEP/.hex with information about the fetched dependency. We diff the information in the manifest file against the lockfile to determine if the the local dependency is outdated and needs to be fetched again to match the lock.
In this case we marked the dependency as outdated because the manifest had a new field :outer_checksum that was missing in the lock.
It happens when you do COPY . . after RUN mix deps.get, because it copies everything from the host to the container, including mix.lock which is potentially outdated compared to the manifest in the container.
Also Liked
gcauchon
Thanks for the detailed explanations AND for shipping 0.20.5 already!
v0.20.5 (2020-02-05)
Enhancements
- Add timestamps to entries in registry cache for easier debugging
- Bump registry cache version to invalidate old caches
- Warn if fetching registry without outer checksum
Bug fixes
- Do not require that the registry supports outer checksums
- Missing outer checksum is not a mismatch, this will fix “out of date” errors when the manifest is newer than the lockfile
Backward compatibility helps a lot as we don’t have to update all our active projects; but will do asap…
Cheers to everyone involved in solving this issue today, the community is amazing…
entone
There was an update to hex last night, there were some other errors prior to the update around parsing the old lock format. I saw similar errors to yours after the update, but a rerun resolved them.
I’m pretty sure it has to do with the docker caching, so you may need to break the cache.
sasajuric
+1 on cache clearing. Spent some time battling similar errors on CI. Removing the cache fixed the problem.
Popular in Questions
Other popular 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
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance










