tino415
Hello all,
today I had interesting problem in our CI/CD pipeline. We set up pipeline so in one container was run mix deps.get, MIX_ENV=test mix deps.compile and MIX_ENV=test mix compile then we copied _build and deps folder to other container and run mix test there. Problem was that after running migrations tests failed on error:
** (Mix) Could not start application ranch: exited in: :ranch_app.start(:normal, []) 00:06
744 ** (EXIT) an exception was raised: 00:06
745 ** (UndefinedFunctionError) function :ranch_app.start/2 is undefined (module :ranch_app is not available) 00:06
746 (ranch 1.8.0) :ranch_app.start(:normal, []) 00:06
747 (kernel 8.3.2.3) application_master.erl:293: :application_master.start_it_old/4
Which got resolved by running MIX_ENV=test mix deps.compile on testing machine. My question is why is that? Is that somehow avoidable? On localhost I never had to run MIX_ENV=test mix deps.compile or MIX_ENV=test mix compile to be able to run mix test and deps.compile takes a lot of time and noticeably slowing down our pipeline.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
BradS2S
So you might be conflating mix test which just runs all the tests in whatever env you are in with the test environment.
My bet would be that your other container has different config settings / different env. So when you take files compiled for one configuration and run it in another you are going to have a bad time.
Look in your mix.exs file and I’m guessing the ranch dependency is set to not be included in test env.
dimitarvp
Your description is a bit confusing. What’s your goal? Running
mix teston a separate, dedicated, VM/machine?tino415
It is actually semaphoreci and they are running separate build process steps in separate docker containers, I think it is similar to running multistage dockerfile
tino415
I tried to verify this and:
depsfoldertestis in copied_build_build/test/lib/ranch/ebin/ranch.appMIX_ENV=test mix testAm I missing something?
BradS2S
It isn’t best practices to copy the _buikd folder and move it. I’m not sure I follow you completely.
dimitarvp
Okay, I get that, but I don’t think straight up copying files is how it’s done. Utilizing multi-stage builds you should be able to just base one image on another. Though I am not sure how does that work with distributing work among different nodes, haven’t tried it.
cjbottaro
Our CI pipeline actually pushes the built Docker image to a registry.
So we have two jobs:
The build job creates the image (compiling both prod and test) and pushes it to an image repo, then the test job pulls down the image and runs a container using a command like
mix test. If the test job passes, then we’re all ready to deploy to prod since the image is already in a repository.Complexity arises when you want to cache your deps, which drastically speeds up the build process.
tino415
I don’t have control over docker files, have only limited api to copy stuff between build steps. Maybe should not compare it to multi stage build. Lets say I have no control over dockerfiles and docker stuff lets say I have simple api where I can define build steps, which every run in different docker container (I even have limited control which image is used) and then I have api to copy files between build steps.
tino415
Yes, but that is not usable in this case, actually we build docker image only on master on prod pipeline, on feature branches I prefer speed.
tino415
I work with what I have. Nov it works, could be 40 seconds faster, but works. But still I would like to know what is going on? Maybe there are some other files that are required to copy to replicate builded project?