chore(deps): bump actions/setup-java from 5 to 6 - #39
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 5 to 6. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@v5...v6) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Approving. Target version verified to exist and be current, and the failing CI
here is not caused by this bump.
I checked every target in this batch against the upstream release list rather
than assuming Dependabot picked a real tag:
mymindstorm/setup-emsdk v16 latest v16 exists
actions/setup-java v6 latest v6.0.0 exists
pnpm/action-setup v6 latest v6.0.10 exists
actions/checkout v7 latest v7.0.1 exists
All current majors.
The red CI is not yours
Every job in this run fails with:
apps/epdf/epdf.h:5:10: fatal error: eapps_core.h: No such file or directory
master does not build, and has not for a while — 48 fatal errors from a clean
clone. The cause is .gitignore:61, a bare core rule intended for Unix core
dumps, which matches any file or directory named core at any depth and
therefore excluded core/, the source tree. core/common/include/eapps_core.h
is included by all 44 app targets and was never committed:
$ git ls-files | grep -c eapps_core.h
0
#42 fixes that. Once it lands, re-run these and the result will mean something.
Merging this before #42 is harmless — it cannot make a build that already fails
fail differently — but the check will stay red until #42 is in.
Worth noting for whoever triages these: a major-version bump of a GitHub Action
can carry breaking changes, and the usual way to find out is CI. That signal is
currently unavailable in this repository for reasons unrelated to any of these
four PRs, so approval here rests on the version existing and the diff being a
pure version string change — not on a green run.
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — eApps#39 "chore(deps): bump actions/setup-java from 5 to 6"
head: 98a0043 author: app/dependabot ci: fail (11 of 11 jobs) — pre-existing on master and unreachable from this diff, see below
Verdict: The bump is clean. One call site, and I checked every user-facing change in v6 against it: the renamed input is not used, the distribution API change affects only zulu, and upstream documents the ESM migration as non-breaking. The finding worth acting on is not the bump — it is that the job being bumped cannot fail, so nothing could tell you if the bump were wrong.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | High | .github/workflows/weekly.yml:186-190 |
The job whose JDK provisioning this PR changes has continue-on-error: true on both its build and its test step: run: ./gradlew build at :186-187 and run: ./gradlew test at :189-190. .ai/reviewer.md names this directly — "a || true on a build or test step, a verification whose result is discarded. Treat these as findings regardless of the reason given" — and the brief adds "do not round severity down". The concrete consequence for this PR: gradle-build reports success whatever setup-java@v6 provisions. If v6 hands the job a JDK that Gradle rejects, the step fails, continue-on-error swallows it, and the job is green. This bump is unfalsifiable by the only check that exercises it. |
Remove continue-on-error: true from both steps. If the Gradle build is known to be broken and the job is being kept as an aspiration, say so where a reader will see it — STATUS.md-style, per §28's claims policy — rather than encoding it as a check that always passes. This is pre-existing and not this PR's to fix, but it is the reason this PR cannot be validated. |
| 2 | Low | .github/workflows/weekly.yml:1-8 |
Reachability: weekly.yml triggers on schedule plus workflow_dispatch only, so nothing on this pull request runs setup-java at any version. The bump first executes in a scheduled run on the default branch, after merge. Combined with finding 1, its first execution also cannot report a failure. |
Nothing to change in this PR. Worth knowing before merging: the merge is the test. |
Nothing else. The change is mechanically complete — grep -rn "setup-java@" .github/workflows/ finds exactly one occurrence and this PR converts it.
CI state
All 11 required checks are red, and the diff cannot have caused any of them. Verified:
- This PR edits one line of
weekly.yml. All 11 failing jobs —Native (ubuntu/windows/macos),Category (web/media/games/security/productivity/connectivity),Sanitizers,JS/TS lane— are defined inci.yml(:20,:45,:75,:95). No change toweekly.ymlcan affect a job inci.yml. - Master run
32813232464(2026-08-25, six days before this PR was opened) failed on the identical 11 jobs at the identical 11 steps. That is the state of the branch point. - Master has since partly recovered: run
33501131456(2026-09-01) fails on only 2 jobs —Native (windows-latest) :: BuildandJS/TS lane :: desktop-apps lint+build.
Rebasing onto current master should reduce this from 11 red to 2. It will not make the bump testable — see findings 1 and 2.
Architecture conformance
Conforms. §21 places CI configuration in the Infrastructure tier; a JDK-provisioning action is build-time only and never a runtime dependency, so §5.1's dependency law is untouched and no eApps source changes. The Gradle/KMP job is Tier-5 application tooling (§21, eBrowser/eOffice as reference applications; §20.1 makes them capability proofs rather than pillars), so a weekly Kotlin build is correctly weekly rather than PR-gating. §28's evidence policy is the section finding 1 sits under: a job that reports success without having verified anything produces no evidence for any status claim, which is the same failure mode as the EOS_ERR_NOT_SUPPORTED-as-success pattern .ai/security.md warns about, in CI form.
Proposed changes
- Merge the bump. It is correct and the alternative — staying on v5 — has no advantage.
- Separately, remove the two
continue-on-error: truelines atweekly.yml:187and:190(finding 1), and let the resulting failure be visible. Whatever it reports is information the repository does not currently have. - Separately, rebase this branch onto current
masterso its check summary is interpretable.
No fix PR opened. Finding 1 is High and the edit is two lines, but removing continue-on-error from a build that is very likely broken turns a green weekly job red without anyone having diagnosed it, and the brief's bar for an unattended fix is a defect whose fix I can verify by running something. I cannot run this repository's Gradle build, so the honest move is to report it and leave the timing to a maintainer.
Verification I ran
- Upstream v6.0.0 release notes (2026-08-24), checked change by change against the one call site:
- "Rename
jdkFileinput tojdk-filewith deprecated alias" — the call site passes onlydistributionandjava-version(weekly.yml:181-183). Not affected, and the alias is retained anyway. - "Migrate from Zulu Discovery API to Azul Metadata API" and "Map Zulu x86 architecture to i686" — these affect
distribution: zulu. This call site usesdistribution: temurin.grep -rn -A4 "setup-java@" .github/workflows/*.ymlconfirmstemurinis the only distribution used anywhere in the repository. - "Migrate to ESM and upgrade dependencies" — upstream shipped a companion doc change in the same release, PR #1090, titled "clarify V6 ESM migration is not a user-facing breaking change".
- Everything else in the release is additive:
.mvn/extensions.xmlin the Maven cache key,cache-primary-keyoutput, asdf.tool-versionsinference, a Maven compiler problem matcher, multi-field versions like18.0.1.1,java-version: latest. None is used here and none changes a default this call site relies on. java-version: "17"is a long-term-support release and is provisioned by Temurin under both majors.
- "Rename
- Runner floor. v5 was the release that moved to Node 24; this PR crosses v5 → v6, so no new runtime floor is introduced. Either way every
runs-on:in eApps is a GitHub-hosted label (ubuntu-latest,windows-latest,macos-latest, or a matrix of those), so no self-hosted runner needs upgrading. - Finding 1: read
weekly.yml:170-191in full.gradle-buildis a three-OS matrix;checkout@v4,setup-java,gradle/actions/setup-gradle@v4, thenBuildandTest, each withcontinue-on-error: true. - Finding 2 and CI attribution: read the
on:block ofweekly.ymland the job definitions inci.yml; compared the failing job/step sets on this PR against master runs32813232464and33501131456viagh run view.
Not checked
- The bump in action. Nothing on this PR runs
setup-java, and I did not dispatchweekly.ymlby hand. I have not observed@v6provision a JDK in this repository; the assessment above is an audit of the changelog against the call site, not an execution. - Whether the Gradle build passes at any JDK version. This is the substance of finding 1:
continue-on-error: truemeans the repository has no record of it either. Whether./gradlew buildcurrently succeeds is Unknown, and it will stay unknown until those two lines come out. - The Kotlin/KMP project itself. I did not look for
build.gradle.kts, a Gradle wrapper version, or asourceCompatibilitysetting, so I cannot say whether Java 17 is the right target for it or whether a Gradle version compatible with it is whatsetup-gradle@v4installs. - The root cause of the 11 pre-existing failures. I established that they pre-date this PR and are unreachable from it; I did not read the logs or diagnose them.
gradle/actions/setup-gradle@v4, the next step in the same job, was not evaluated — it is not part of this diff, and no dependabot PR for it is open.
Automated architecture review of 98a0043982ec — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.
1 participant
Bumps actions/setup-java from 5 to 6.
Release notes
Sourced from actions/setup-java's releases.
... (truncated)
Commits
dd06d9cPrepare documentation for v6 release (#1253)59b3450chore(deps): combine open Dependabot npm updates (#1252)b96213dSet default signature verification for supported distributions (#1246)1dbac3cdocs: expose contributing guide to GitHub (#1245)11741d6ci: constrain cache e2e job modes (#1244)ff99aa1Fix Oracle macOS E2E version (#1243)416c6d1Add Red Hat Build of OpenJDK support (#1241)5f75b27Add Maven dependency-resolution repositories (#1240)a42a52cAdd multiple Maven server credentials (#1239)fb4abd7test: cover JDK 26 from SDKMAN (#1238)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)