From 842deabe3720872597426842233c805567bb455f Mon Sep 17 00:00:00 2001 From: Roberto Tyley Date: Wed, 6 Dec 2023 17:22:30 +0000 Subject: [PATCH] Avoid sbt cache being invalidated for a library that is only incrementing it's own version While working on https://github.com/guardian/gha-scala-library-release-workflow I noticed that no matter how many times I ran the workflow, `actions/setup-java` would always report `sbt cache is not found`, even if there had been no substantial change in the project - simply that `version.sbt` (the file used by https://github.com/sbt/sbt-release) had the version number in it incremented (as in https://github.com/guardian/play-secret-rotation/commit/b2152325baf80f57e7c510fe03ccda5596c139d6). 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 orginally introduced with https://github.com/actions/setup-java/pull/302 --- src/cache.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/cache.ts b/src/cache.ts index f75c8dfd5..b44d4813c 100644 --- a/src/cache.ts +++ b/src/cache.ts @@ -58,7 +58,8 @@ const supportedPackageManager: PackageManager[] = [ '**/*.sbt', '**/project/build.properties', '**/project/**.scala', - '**/project/**.sbt' + '**/project/**.sbt', + '!**/version.sbt' // releasing a new version of a library project shouldn't invalidate the entire sbt cache ] } ];