Smarter caching in CI

[armanbilge]

Two Three things to consider:

• cache all deps, not just sbt deps
• be robust to different ci jobs that may download different deps (e.g., jvm vs js vs scalafix vs site)
• don't get invalidated by simple changes tobuild.sbt etc.

[armanbilge]

One idea to fix might be to determine the cache key not just from the build configuration, but also from the matrix. Effectively each job in the matrix would get its own cache.

GH actions supports caches of up to 10 GB before it starts evicting old caches. If each job gets its own cache this could add up real quick, at which point it would be useless.

[DavidGregory084]

GH actions supports caches of up to 10 GB before it starts evicting old caches. If each job gets its own cache this could add up real quick, at which point it would be useless.

Perhaps this could be mitigated by using restore keys, provided the keys were prefixed in a way that allowed the cache to be layered nicely

[armanbilge]

That's a good point. I'd say if we can get sbt and plugins out of the cache then it's a win. Library deps are icing on the cake :)

[armanbilge]

Seems we may be caching some files we are not supposed to, like *.lock and ivydata-*.properties. This should be fixed as well.
https://www.scala-sbt.org/1.x/docs/GitHub-Actions-with-sbt.html#Caching

[armanbilge]

The setup-java action now supports caching. I think we should just use that and call it a day.

• Setup java cache #300

[armanbilge]

See also some discussion about why the "smarter caching" proposal that was originally the goal of this issue, actually would not work. tl;dr if you use the restore key to fallback to a non-exact-match cache, then when you create a new cache it will also include unnecessary stuff from the fallback cache. This causes your cache to grow unboundedly.

• Gradle cache increases by 400 MB every time updating Gradle wrapper version actions/setup-java#269
• Provide a mechanism to have a per file cache eviction/retention actions/cache#788