Merge ed3ab602f8 into 5896cecc08

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 b2152325ba).

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

@@ -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
     ]
   }
 ];
@@ -92,13 +93,15 @@ async function computeCacheKey(
   const pattern = cacheDependencyPath
     ? cacheDependencyPath.trim().split('\n')
     : packageManager.pattern;
-  const fileHash = await glob.hashFiles(pattern.join('\n'));
+  const fileHash = await glob.hashFiles(pattern.join('\n'), undefined, undefined, true);
   if (!fileHash) {
     throw new Error(
       `No file in ${process.cwd()} matched to [${pattern}], make sure you have checked out the target repository`
     );
   }
-  return `${CACHE_KEY_PREFIX}-${process.env['RUNNER_OS']}-${packageManager.id}-${fileHash}`;
+  const cacheKey = `${CACHE_KEY_PREFIX}-${process.env['RUNNER_OS']}-${packageManager.id}-${fileHash}`;
+  core.info(`cacheKey is ${cacheKey}`);
+  return cacheKey;
 }
 
 /**