Architecture validation for JDK file installs (#1324)

* Enhance architecture validation and error handling

* Improve architecture normalization and validation for custom tokens

* Refactor architecture validation to consolidate error handling for invalid tokens
This commit is contained in:
v-mahabaleshwars
2026-11-13 23:04:15 -05:00
committed by GitHub
parent 77dd5b2ce2
commit 9ce5b12cb9
5 changed files with 67 additions and 11 deletions
+5 -4
View File
@@ -659,9 +659,10 @@ runner, distribution, JDK size, network, and cache eviction pressure.
The `architecture` input is normalized before setup-java checks the tool cache
or contacts a vendor. `amd64`, `ia32`, `arm`, and `arm64` are accepted aliases
for `x64`, `x86`, `armv7`, and `aarch64`. The table lists the combinations
setup-java validates up front; an individual Java patch release can still be
absent from a vendor catalog.
for `x64`, `x86`, `armv7`, and `aarch64`. Every value must be one token that
starts with a letter or digit and contains only letters, digits, `_`, or `-`.
The table lists the combinations setup-java validates up front; an individual
Java patch release can still be absent from a vendor catalog.
| Distribution | Linux | macOS | Windows | Other / version restrictions |
| --- | --- | --- | --- | --- |
@@ -1651,4 +1652,4 @@ Notes and caveats:
- On **self-hosted runners**, importing into a tool-cache JDK persists for as long as that cached version remains on the runner; if you want it to survive JDK reinstalls, pre-seed the CA into your runner image or re-run the import step each time.
- Prefer giving the certificate a stable, descriptive `-alias` so re-runs are idempotent (re-importing the same alias will fail; add `keytool -delete -alias internal-ca ...` first if you re-run within a long-lived runner).
This documents the post-install workflow; there is no dedicated action input for supplying a custom `cacerts` file.
This documents the post-install workflow; there is no dedicated action input for supplying a custom `cacerts` file.