Merge ed3ab602f8 into a1c6c9c867

Updated advanced-usage.md (#622 )
* Update advanced-usage.md * Update advanced-usage.md * Update advanced-usage.md * Update README.md * Update advanced-usage.md
2026-06-27 23:50:01 +00:00 · 2024-05-06 15:11:30 +02:00 · 2024-05-03 08:29:31 -05:00 · 2024-02-22 15:57:56 +00:00 · 2023-12-07 12:06:46 +00:00
6 changed files with 4551 additions and 4386 deletions
--- a/README.md
+++ b/README.md
@ -91,8 +91,8 @@ steps:
 #### Supported version syntax
 The `java-version` input supports an exact version or a version range using [SemVer](https://semver.org/) notation:
 - major versions: `8`, `11`, `16`, `17`, `21`
- more specific versions: `17.0`, `11.0`, `11.0.4`, `8.0.232`, `8.0.282+8`
- early access (EA) versions: `15-ea`, `15.0.0-ea`, `15.0.0-ea.2`, `15.0.0+2-ea`
+- more specific versions: `8.0.282+8`, `8.0.232`, `11.0`, `11.0.4`, `17.0`
+- early access (EA) versions: `15-ea`, `15.0.0-ea`

 #### Supported distributions
 Currently, the following distributions are supported:
--- a/dist/cleanup/index.js
+++ b/dist/cleanup/index.js
--- a/dist/index.js
+++ b/dist/index.js
--- a/dist/setup/index.js
+++ b/dist/setup/index.js
--- a/docs/advanced-usage.md
+++ b/docs/advanced-usage.md
@ -526,19 +526,19 @@ steps:
 ```

 ## Java version file
-If the `java-version-file` input is specified, the action will extract the version from the file and install it.
-
-Supported files are .java-version and .tool-versions.
-In .java-version file, only the version should be specified, e.g., 17.0.7.
-In .tool-versions file, java version should be preceded by the java keyword, e.g., java 17.0.7.
-.java-version recognizes all variants of the version description according to [jenv](https://github.com/jenv/jenv) and .tool-version recognizes all variants of the version description according to [asdf](https://github.com/asdf-vm/asdf).
-
-If both java-version and java-version-file inputs are provided, the java-version input will be used.
+  If the `java-version-file` input is specified, the action will extract the version from the file and install it.
+  
+  Supported files are .java-version and .tool-versions.
+  In .java-version file, only the version should be specified (e.g., 17.0.7).
+  In .tool-versions file, java version should be preceded by the java keyword (e.g., java 17.0.7).
+  The `.java-version` file recognizes all variants of the version description according to [jenv](https://github.com/jenv/jenv). Similarly, the `.tool-versions` file supports version specifications in accordance with [asdf](https://github.com/asdf-vm/asdf) standards, adhering to Semantic Versioning (semver).
+  
+  If both java-version and java-version-file inputs are provided, the java-version input will be used.

 Valid entry options:
 ```
 major versions: 8, 11, 16, 17, 21
-more specific versions: 1.8.0.2, 17.0, 11.0, 11.0.4, 8.0.232, 8.0.282+8
+more specific versions: 8.0.282+8, 8.0.232, 11.0, 11.0.4, 17.0
 early access (EA) versions: 15-ea, 15.0.0-ea
 versions with specified distribution: openjdk64-11.0.2
 ```
--- 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
    ]
  }
 ];
@ -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;
 }

 /**
Author	SHA1	Message	Date
Roberto Tyley	77834093c9	Merge `ed3ab602f8` into `a1c6c9c867`	2024-05-06 15:11:30 +02:00
mahabaleshwars	a1c6c9c867	Updated advanced-usage.md (#622 ) * Update advanced-usage.md * Update advanced-usage.md * Update advanced-usage.md * Update README.md * Update advanced-usage.md	2024-05-03 08:29:31 -05:00
Roberto Tyley	ed3ab602f8	Is version.sbt still being included...	2024-02-22 15:57:56 +00:00
Roberto Tyley	f228ab54b9	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 `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	2023-12-07 12:06:46 +00:00