Ping?

Pinging as well.

I noticed the example in @mhanberg's https://www.mitchellhanberg.com/ci-cd-with-phoenix-github-actions-and-gigalixir/ uses separate caches for deps and _build, and the _build cache key includes the Elixir and Erlang version. Would that make sense in this example?

It should not be required to include the versions in the cache key since Elixir should recompile when it detects the Elixir version has changed. It does not recompile when the OTP version changes but that is rarely necessary.

@jclem Sorry to bother you – you came to my aid once before when an "Actions" PR got stuck in limbo. Could we get this one considered?

Sorry all, I don't maintain this repo and didn't get notified (it has an owner, just not me).

Is this actually an effective way of caching _build? My understanding is that this will only rebuild the cache when mix.lock changes, and so you'll end up with the same cache for all builds regardless of what other files change.

I'd considered adding this before, myself, but couldn't figure out the right way of doing it.

I'm unfortunately on PTO until a week from this Monday, but I've set a reminder to revisit this when I'm back. I'm sorry for the delay, and thanks for bringing this to my attention.

Is this actually an effective way of caching _build? My understanding is that this will only rebuild the cache when mix.lock changes, and so you'll end up with the same cache for all builds regardless of what other files change.

It will use the cache for dependencies but mix will detect the changes in the project itself and rebuild it accordingly.

Oh yeah, sorry—my point wasn't that the caching itself would be problematic, just that the cache wouldn't be helpful because we're only using the mix.lock hash as the key (so changing application code wouldn't get cached over time unless mix.lock happens to change).

That said, the benefit that it does add, however, is that you get cached built dependencies, which for a lot of projects is probably the majority of build time in CI, anyway. Given that, 👍 from me!

Thank you so much, @jclem! Really appreciate it.

Thank you for merging! 💜

It will use the cache for dependencies but mix will detect the changes in the project itself and rebuild it accordingly.

out of curiosity, and sorry if it's not the best place to ask such questions, if we have a build matrix (e.g. simply different OSes but you can imagine different Elixir/OTP pairs too) we'd get better cache utilisation with separate one for deps and build, right?

- uses: actions/cache@v2
   with:
     path: deps
     key: mix-deps-${{ hashFiles('**/mix.lock')) }}
     restore-keys: mix-deps-
- uses: actions/cache@v2
   with:
     path: _build
     key: mix-build-${{ runner.os }}

What is merged in is definitely a better starting point for most users of course.

out of curiosity, and sorry if it's not the best place to ask such questions, if we have a build matrix (e.g. simply different OSes but you can imagine different Elixir/OTP pairs too) we'd get better cache utilisation with separate one for deps and build, right?

Yes. deps/ does not require the OS/OTP/Elixir version in its key but you still want to include mix.lock in the _build/ cache key.