Bump actions/setup-java to v3.14.1 with zulu distribution#774
Merged
hectorcast-db merged 2 commits intomainfrom Apr 22, 2026
Merged
Bump actions/setup-java to v3.14.1 with zulu distribution#774hectorcast-db merged 2 commits intomainfrom
hectorcast-db merged 2 commits intomainfrom
Conversation
The setup-build-environment composite action was pinned to
actions/setup-java@v1.4.4 (Aug 2020). On arm64 macos-latest runners
(Image: macos-15-arm64) v1.4.4 resolves JDKs under the legacy
x64-only tool cache path and intermittently fails with:
JAVA_HOME: /Users/runner/hostedtoolcache/jdk/8.0.492/x64
The JAVA_HOME environment variable is not defined correctly,
this environment variable is needed to run this program.
Observed on PR #773 run 24765873049, jobs unit-tests
(macos-latest, 8), (macos-latest, 11), and (macos-latest, 17). Java
20 on the same commit passed, and the same workflow on the same
commit SHA has alternated between pass and fail, confirming the
x64/arm64 mismatch is the root cause.
release.yml and package.yml already use v3.14.1 with
distribution: "adopt"; this change aligns setup-build-environment
with them.
Co-authored-by: Isaac
First attempt used distribution: "adopt" to mirror release.yml / package.yml. release.yml runs on ubuntu-latest (x64) where adopt ships Java 8, but this composite action is also used on macos-latest (arm64) where adopt has dropped Java 8 — only 11+ are published. On PR #774 run 24767042972 unit-tests (macos-latest, 8) failed at setup-java with: Could not find satisfied version for SemVer '8'. Available versions: 26.0.0+35, 25.0.2+10.0.LTS, ..., 11.0.15+10 Switching to zulu, which publishes Java 8 for arm64 macOS. zulu also matches the default used by setup-java v1.4.4 before this bump, so behavior under the composite action on existing callers is unchanged for x64. release.yml and package.yml still use adopt; they only run on ubuntu so they are unaffected. Co-authored-by: Isaac
Contributor
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
tejaskochar-db
approved these changes
Apr 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fixes intermittent CI failures on arm64 `macos-latest` runners for PRs touching anything unrelated to the workflow itself.
The `setup-build-environment` composite action was pinned to `actions/setup-java@v1.4.4` (August 2020). That version hard-codes an x64 tool-cache path. Current `macos-latest` runners are arm64 (Image: `macos-15-arm64`), so v1.4.4 intermittently lands on a non-existent JDK path and fails with:
```
JAVA_HOME: /Users/runner/hostedtoolcache/jdk/8.0.492/x64
The JAVA_HOME environment variable is not defined correctly,
this environment variable is needed to run this program.
```
Observed today on PR #773 run 24765873049 — jobs `unit-tests (macos-latest, 8)`, `(macos-latest, 11)`, `(macos-latest, 17)` all failed at the JDK setup step. Java 20 on the same commit passed, and a subsequent re-run of the same SHA hit the same three failures, confirming this is not transient.
`release.yml` and `package.yml` in this repo already use `actions/setup-java@v3.14.1` with `distribution: "adopt"`; this change brings `setup-build-environment` in line with them.
Change
Test plan
This pull request was AI-assisted by Isaac.
NO_CHANGELOG=true