chore(deps): bump actions/setup-java from 4 to 6 - #35
Conversation
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 4 to 6. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@v4...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. I verified the target exists and is current rather than assuming
Dependabot picked a real tag:
actions/setup-java target v6 latest confirmed on the upstream release list
The diff is a pure version-string change.
But be aware there is no CI behind this
The only check on this PR is a skipped assign job. That is not a quirk of this
PR — this repository's CI has not run since 2026-05-31.
# .github/workflows/ci.yml
on:
push:
branches: [main, develop]
pull_request:
branches: [main]default branch: master
main: 404 Branch not found
main was renamed or deleted around late May and the workflow was left pointing
at it. Every push to master and every pull request against it falls outside the
trigger. Filed as #38.
That matters here specifically. A major version bump of a GitHub Action is
exactly the change CI exists to validate — new runtimes, removed inputs, changed
defaults — and there is none. Approval rests on the version existing and the diff
being mechanical, not on evidence the workflow still works.
I would rather these merged after #38 than before, so the first thing the
restored CI reports is whether these bumps are good. But they are not
individually risky and I am not going to hold them for it.
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — eAI#35 "chore(deps): bump actions/setup-java from 4 to 6"
head: d5a7020 author: app/dependabot ci: none ran
Verdict: A two-line major-version bump of a CI action, in two workflows, neither of
which can run on this pull request. The bump is probably fine; the point is that nothing
here can tell you that, and the reason is a trigger defect worth fixing on its own.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | High | .github/workflows/cross-platform-hal.yml:12-17 |
The pull_request: trigger is path-filtered to platform/**, accel/**, formats/**, common/**. A change to the workflow file itself matches none of them, so this workflow cannot test changes to itself. That is why checks.txt for this head contains one entry, assign / skipping, and nothing else. A major-version bump of setup-java lands with zero validation, and every future edit to this workflow will too. |
Add .github/workflows/cross-platform-hal.yml (or .github/workflows/**) to both paths: lists, so the workflow re-runs when it is edited. |
| 2 | Medium | .github/workflows/cross-platform-hal.yml:5 (and ci.yml) |
push: branches: [main, develop]. git ls-remote shows this repository has master and release — there is no main and no develop. .github/STANDARDS.md ("Release model") states every repo has exactly those two long-lived branches. So the push trigger has never fired and cannot. Combined with finding 1, cross-platform-hal.yml currently runs only on workflow_dispatch and on PRs that touch four source directories. |
Already addressed by open PR eAI#39 "ci: run the build-and-test workflow on master". Finding 1 belongs in that PR too — it is the same trigger block, and a second PR editing the same lines would conflict with it. I have opened nothing for that reason. |
| 3 | Medium | .github/workflows/release.yml:171 |
The second setup-java@v6 is in a workflow triggered only by push: tags: v*.*.*. Nothing exercises it before a real release, so the first time this bump runs will be during an actual release build, where failure is most expensive. This is a consequence of findings 1-2 rather than a separate defect, but it changes the risk: one of the two edits is untestable by design. |
Before merging, run the Android leg once via workflow_dispatch on this branch, or dry-run the release workflow on a throwaway pre-release tag. Record the result in the PR. |
| 4 | Low | both files | The actions are pinned to mutable major tags (@v4 → @v6), not to commit SHAs. .github/STANDARDS.md lists OpenSSF Scorecard under org-wide security frameworks, and Scorecard's Pinned-Dependencies check scores mutable tags as unpinned — v6 can be repointed at any commit by the action's owner. Every uses: in these two workflows has the same property, so this is a repo-wide posture item that this PR merely touches. |
Pin to full commit SHAs with a trailing # v6.x.y comment. Dependabot maintains SHA pins and updates the comment, so this costs nothing ongoing. Worth one PR across all workflows rather than piecemeal. |
I have not repeated the missing github-actions label point — Dependabot already raised it
in the existing comments.
Architecture conformance
No architectural impact. eAI is Tier 3 — Advanced (§21), and this is CI configuration
inside it: no #include, import, link line or manifest dependency changes, so §5.1 is not
engaged. The one design rule that touches this area is §28's evidence model — "Do not
represent proposed or planned capabilities as implemented until the evidence model in this
document is satisfied" — and findings 1-3 are precisely a case where the repository cannot
produce evidence for a change to its own build.
Proposed changes
- Land eAI#39 first, folding finding 1 into it. That restores a signal to this repository.
- Re-run this PR afterwards so the bump is actually exercised, then merge on that evidence
rather than on the assumption that a Dependabot bump is safe. - If the release-workflow leg (finding 3) still cannot be exercised, say so in the merge
comment rather than letting a green tick imply it was.
Merging this before step 1 is not dangerous — distribution: temurin and java-version: 17
are set explicitly at both call sites, so the defaults most likely to shift across a major
bump are overridden. It is just unverified, and should be described that way.
Not checked
actions/setup-java@v6's changelog was not read. I did not check what changed
between v4, v5 and v6, whether v6 requires a newer runner image, or whether any input
used here was renamed or removed. Both call sites setdistributionandjava-version
explicitly, which covers the common default-drift risk, but I am not claiming the bump
is behaviour-neutral — only that the two inputs present are still the documented ones.- Nothing was executed. No workflow ran on this head (
assign / skippingis the only
entry inchecks.txt), and I did not run GitHub Actions locally. There is no evidence
in this bundle that eAI's Android build works withsetup-java@v6. That is the finding,
not an omission in the review. - The Android/HAL job itself was not examined beyond its
setup-javastep — whether it
passes today onv4is unknown to me, since the workflow's triggers mean it has not run
recently on this branch either. - I did not check the remaining two open Dependabot PRs (eAI#36
actions/cache4→6, eAI#37
actions/setup-python5→7) for the same trigger problem, though findings 1 and 2 apply
to any of them that touch these two workflows.
Automated architecture review of d5a70206925c — 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 4 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)