chore(deps): bump actions/cache from 4 to 6 - #36
Conversation
Bumps [actions/cache](https://github.com/actions/cache) from 4 to 6. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@v4...v6) --- updated-dependencies: - dependency-name: actions/cache dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
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/cache 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#36 "chore(deps): bump actions/cache from 4 to 6"
head: aaae9eb author: app/dependabot ci: none (no checks ran on this PR)
Verdict: The bump itself is safe — I checked both intervening majors against the step's actual inputs and nothing it uses changed. The problem is that the workflow it edits runs on neither a master push nor this pull request, so the change is unverifiable now and unexercised after merge.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | Medium | .github/workflows/cross-platform-hal.yml:6-7, :12-14 |
The edited workflow never runs. Its push trigger is branches: [main, develop], and this repository's default branch is master (verified: gh api repos/embeddedos-org/eAI --jq .default_branch → master; .github/STANDARDS.md "Release model" mandates master + release and lists no main). Its pull_request trigger carries paths: platform/**, accel/**, formats/**, common/**, which a PR touching only .github/workflows/ does not match. Both halves miss, which is why gh pr checks 36 reports only the assign job. A cache-action bump whose only effect is inside a workflow that never executes cannot be validated by anything. |
Already covered by the open eAI#39 ("ci: run the build-and-test workflow on master") — do not duplicate it here. Once #39 lands, rerun this PR so the bump is actually exercised before merge. |
| 2 | Low | .github/workflows/cross-platform-hal.yml:184-187 |
Pre-existing, in the step being edited: the cache key is android-${{ matrix.abi }}-${{ hashFiles('CMakeLists.txt', 'platform/**', 'accel/**', 'common/**') }}, and it caches the CMake build tree (path: build-android-${{ matrix.abi }}). The NDK version is not in the key, while the preceding step pins nttld/setup-ndk@v1 with ndk-version: r26d (:178-182). Bump the NDK and the job restores a build tree produced by the previous toolchain, with CMake's cached compiler paths inside it. Not caused by this PR — but if actions/cache is being touched, the key is the thing worth getting right. |
Add the NDK version to the key: key: android-${{ matrix.abi }}-ndk-r26d-${{ hashFiles(...) }}, ideally reading r26d from a single variable shared with the setup-ndk step. |
Architecture conformance
Conforms. §21 places .github / CI templates in the Infrastructure tier, and a CI action version is not a runtime dependency, so §5.1's dependency law is not engaged in either direction — nothing in eAI's Tier-3 code, and nothing below it, is affected. .github/STANDARDS.md names OpenSSF Scorecard among the org's security frameworks; Scorecard's Pinned-Dependencies check wants actions pinned by commit SHA rather than by floating major tag, and this repository pins by tag throughout. That is a pre-existing org-wide posture, not something this PR should change unilaterally, but it is the reason a "bump 4 → 6" is a trust decision rather than a version number.
Proposed changes
- Land eAI#39 so
cross-platform-hal.ymlruns onmaster, then rerun this PR's checks and merge on green. - Optionally fold finding 2 into this PR — it is one line in the step already being modified.
No fix PR opened: finding 1 is already owned by eAI#39, and finding 2 is a judgement call about cache-key composition rather than a provable defect.
Verification I ran
- Read the upstream release notes for both majors crossed. v5.0.0 (2025-12-11): sole change is "Upgrade to use node24", requiring Actions Runner ≥ 2.327.1. v6.0.0 (2026-06-23): sole change is "Update packages, migrate to ESM". Neither release removes, renames or changes the semantics of an input.
- The step uses only
pathandkey(:186-187) — norestore-keys, nosave-always, nolookup-only,fail-on-cache-miss,enableCrossOsArchiveorupload-chunk-size. Nothing in the v5/v6 changelogs touches what this step passes. - Runner requirement is satisfied: every
runs-on:in this repository is a GitHub-hosted label (ubuntu-22.04,ubuntu-latest,windows-latest,macos-latest, or a matrix of those). No self-hosted runner needs updating first. actions/cache@v4appears exactly once in the repository (cross-platform-hal.yml:185), so this is the complete change — no second call site was missed.- Finding 1: read the full
on:block; confirmed the default branch via the API; confirmed withgh pr checks 36that onlyassignreported.
Not checked
- The bump in action. No CI ran on this PR (finding 1) and I did not trigger the workflow by hand, so I have not observed
actions/cache@v6restore or save this cache. Correctness here rests on the upstream changelogs plus the input audit above, not on an execution. That is the whole substance of finding 1. - Whether the Android job passes at all. The workflow has not run on
masterfor as long as the trigger has been wrong, so I have no baseline. Whether the cache step is currently helping, hurting, or silently missing on every run is Unknown. - ESM-migration side effects. v6's ESM change is described upstream as internal. I did not audit
actions/cache's own dependency tree or verify behaviour on the Windows and macOS runners in the matrix. - SHA pinning. Not changed by this PR and not evaluated as a proposal; raised above only as context for the Scorecard claim in
STANDARDS.md.
Automated architecture review of aaae9eb6cd5f — 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/cache from 4 to 6.
Release notes
Sourced from actions/cache's releases.
... (truncated)
Changelog
Sourced from actions/cache's changelog.
... (truncated)
Commits
55cc834Merge pull request #1768 from jasongin/readonly-cached8cd72fBump@actions/cacheto v6.1.0 - handle cache write error due to RO token2c8a9bdMerge pull request #1760 from actions/samirat/esm_migration_and_package_updatee9b91fdPrettier fixese4884b8Rebuild dist10baf01Fixed licensese39b386Fix test mock return orderb692820PR feedback6074912Rebuild dist bundles as ESM to match type:module5a912e8Fix lint and jest issuesDependabot 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)