Just ran into a somewhat similar issue (erlang deps didn’t seem to be cached) and in my case the problem was in not caching deps folder after running mix compile. This is important since rebar3 actually stores ebins in deps, and in _build mix only creates symlinks.

So, my approach before (which had the same problem as in OP):

# deps stage
- cache pull deps
- mix deps.get
- cache push deps

# compile stage
- cache pull deps, _build
- mix compile
- cache push _build

and my approach now:

# deps stage
- cache pull deps
- mix deps.get
- cache push deps

# compile stage
- cache pull deps, _build
- mix compile
- cache push deps, _build # <-- !!!

Once for each stage, yes. Otherwise mix complains about missing dependencies.

We were made aware of this recently and got it fixed. Didn’t realize all compilation wasn’t done to deps by mix

The rebar3 version installed by mix should now be 3.13.1 which supports an additional argument of where to send output.

I’m not sure what version of mix uses the new output option… Will go look in a bit.

Verified this is not yet supported in mix and likely won’t get attention until the end of May.

So if someone has time and wants to patch mix before then it’d be a great help. The change is to add -o <outputdir> where outputdir is the path to the dep under _build/ to the rebar3 bare compile command mix runs, if rebar3 version is >= 3.13.1 (or error if it fails with “invalid option” and tell the user to upgrade rebar3 I guess).

Are you caching both the deps and build folders? On circle ci we’re caching them both separately

      # restore deps cache
      - restore_cache:
          keys:
            # CI_CACHE_VERSION is used to manually bust the cache
            - messages-deps-v9-{{ .Environment.CI_CACHE_VERSION }}-{{ .Branch }}-{{ checksum "mix.lock" }}
            - messages-deps-v9-{{ .Environment.CI_CACHE_VERSION }}-{{ .Branch }}
            - messages-deps-v9-{{ .Environment.CI_CACHE_VERSION }}-

      # restore build cache
      - restore_cache:
          keys:
            - messages-build-v9-{{ .Environment.CI_CACHE_VERSION }}-{{ .Branch }}
            - messages-build-v9-{{ .Environment.CI_CACHE_VERSION }}-

Then steps related to compiling and running migrations. After that we can save the cache:

      # save deps cache
      - save_cache:
          key: my-app-deps-v9-{{ .Environment.CI_CACHE_VERSION }}-{{ .Branch }}-{{ checksum "mix.lock" }}
          paths: "deps"
      - save_cache:
          key: my-app-deps-v9-{{ .Environment.CI_CACHE_VERSION }}-{{ .Branch }}
          paths: "deps"
      - save_cache:
          key: my-app-deps-v9-{{ .Environment.CI_CACHE_VERSION }}-
          paths: "deps"

      # save build cache
      - save_cache:
          key: my-app-build-v9-{{ .Environment.CI_CACHE_VERSION }}-{{ .Branch }}
          paths: "_build"
      - save_cache:
          key: my-app-build-v9-{{ .Environment.CI_CACHE_VERSION }}-
          paths: "_build"

There’s multiple caches so that if for example the mix.lock changes then we can fallback to the next most recently used cache. Also the v9 is there so that when we make large changes we can cache bust everything and we can do something similar by changing the CI_CACHE_VERSION env variable (but we can change this without pushing a code update). A reason you’d need to bust the cache is when a library reads from application config during compilation (a great example is the Elixir mime type plug: https://hexdocs.pm/mime/MIME.html).

Here’s the official CircleCi elixir guide (although I don’t find it super helpful): https://circleci.com/docs/2.0/language-elixir/

I hope that helps!