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