Avoid sbt
cache being invalidated for a library that is only incrementing its own version
#564
+182,639
−47,289
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
While working on
guardian/gha-scala-library-release-workflow
I noticed that no matter how many times I ran the workflow,actions/setup-java
would always reportsbt cache is not found
, even if there had been no substantial change in the project - simply that the version number inversion.sbt
(the file used bysbt/sbt-release
) had been incremented (as in guardian/play-secret-rotation@b215232).This meant that turning on
cache: sbt
would actually slow the workflow considerably, as it would never benefit from the cache being present, and would always have to save it, which could take 2-3 minutes - even though it can't take advantage of the data it's saving.As such, it would be great to exclude
version.sbt
files from the cache hash key.Background:
cache: sbt
was originally introduced with #302 - cc @fmeriaux 🙇♂️Check list: