chore(deps): bump actions/download-artifact from 4 to 8 - #24
chore(deps): bump actions/download-artifact from 4 to 8#24dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4 to 8. - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](actions/download-artifact@v4...v8) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-version: '8' 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, with a caution proportional to the size of the jump.
Verified
actions/download-artifact v8 exists and is current (latest
v8.0.1). The diff is a pure version-string
change across the workflows.
This is v4 → v8, four majors
Most of this batch moves one major. This one does not, and the intermediate
majors are where behaviour changed — actions/download-artifact in particular
altered artifact naming and matching semantics across v4/v5, so a workflow that
uploads under one name and downloads by pattern can silently retrieve nothing
rather than fail.
The check most likely to catch that is an end-to-end run that uploads and then
downloads an artifact in the same workflow. Worth confirming that path exists
here before merging, because a download that quietly returns zero files produces
a downstream error that looks like anything but a version bump.
The failing checks are not this PR
Lint & Format and Quick Checks fail identically on all five open Dependabot
PRs and on master. Reproduced locally against master:
$ ruff check eosim/
Found 324 errors.
$ ruff format --check eosim/
178 files would be reformatted, 15 files already formatted
Pre-existing, inherited by every PR. Worth fixing separately — a permanently red
check trains people to ignore it — but not a reason to hold this.
Approving because the version is real and the change is mechanical. If anything
in this repository round-trips artifacts between jobs, I would want one green run
of that path before merging rather than after.
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — EoSim#24 "chore(deps): bump actions/download-artifact from 4 to 8"
head: a0ef1f8 author: app/dependabot ci: fail (Lint & Format, Quick Checks — pre-existing on master, not caused by this PR)
Verdict: The riskiest of the five open EoSim dependabot PRs, and the only one I would not merge as-is. It crosses four major versions with documented breaking changes, it leaves actions/upload-artifact on v4 so the pair is now split across majors, and every one of the five changed lines sits on a path that no pull request can execute — three feed the PyPI publish and the GitHub Release, two feed the book-PDF release attach. The first execution of this change would be a release. That is the wrong place to discover an artifact-download regression.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | Medium | .github/workflows/release.yml:126,131,206 and .github/workflows/book-build.yml:240,284 | download-artifact moves to v8 while upload-artifact stays on v4, in the same workflows, on the same artifacts. release.yml:46,69 upload dist and documentation with @v4; :126,:131,:206 now download them with @v8. book-build.yml:224 uploads the PDF with @v4; :240,:284 download it with @v8. Reading the v5-v8 release notes, I expect this to work — v4 uploads are zipped, so v8's new Content-Type check finds application/zip and still decompresses, and v8's digest-mismatch: error default only fires on genuine corruption — but that is inference from release notes, not something anyone has run. Split-major pairs are exactly the configuration upstream tests least. |
Bump the pair together. Either extend this PR to move upload-artifact to the matching major, or hold it until dependabot opens the upload-artifact PR and merge the two as one change. |
| 2 | Medium | .github/workflows/release.yml:206 | The blast radius is the publish path, and it is untestable from a PR. release.yml:206 downloads dist and hands it straight to pypa/gh-action-pypi-publish@release/v1 under environment: pypi with OIDC (id-token: write). :126/:131 feed the GitHub Release. release.yml triggers on tag push only; book-build.yml's two consumers are gated if: github.event_name == 'release' || startsWith(github.ref, 'refs/tags/') and if: github.event_name == 'push' && github.ref == 'refs/heads/master'. No PR run can reach any of the five changed lines. If v8 misbehaves against a v4-uploaded artifact, it surfaces mid-release, after the tag is pushed and immutable. |
Before merging, prove it once: push a throwaway pre-release tag (v0.0.0-artifact-test) on a branch, or add a workflow_dispatch entry to release.yml that runs build → download and stops short of publish. Paste the download step's log into the PR. |
| 3 | High | .github/workflows/ci.yml:263-278, repo branch protection, .github/workflows/ci.yml:226 | The three pre-existing CI-integrity defects detailed with evidence in the EoSim#21 review apply identically: ci-summary cannot fail (it reported pass in 5s on this PR while lint failed and five jobs were skipped), master has required_status_checks: null so nothing gates merge, and pip-audit --strict 2>/dev/null || true makes Security Scan report success unconditionally. This PR is UNSTABLE APPROVED MERGEABLE — one click from landing findings 1 and 2 with no evidence at all. Not introduced by this diff. |
See the EoSim#21 review for the ordered fix. |
| 4 | Medium | CI state — Lint & Format, Quick Checks | Both red on pre-existing ruff violations in eosim/ (I001, F401, UP031, N806 across eosim/analysis, eosim/api, eosim/artifacts, eosim/cli, eosim/plugins, eosim/tests), unrelated to this diff. Every job declaring needs: lint was skipped. Note that fixing lint would still not exercise this PR — see finding 2. |
Land a ruff check --fix / ruff format pass on master separately. |
Recorded as checked, and as the reason finding 1 is Medium rather than High. The v5→v8 breaking changes, from the release notes in the PR body: v6/v7 move to Node 24 (ubuntu-latest satisfies the Actions Runner ≥ 2.327.1 floor); v8 converts to ESM ("transparent to the caller"); v8 stops unzipping downloads whose Content-Type is not zip, with skip-decompress to opt out; v8 changes digest-mismatch from warn to error by default. None of the five call sites pass merge-multiple, pattern, or any input beyond name: and path:, so no input was renamed out from under them. The digest change is a security improvement and only fires on real corruption. My concern is not that a specific bullet breaks this repo — it is that nothing in this repository will ever execute the change before a release does.
Architecture conformance
Conforms. Infrastructure-tier change (master design §21) to a Tier-1 Foundation repository. No source, #include, link line or manifest entry — §5.1 dependency direction untouched. Findings 2-3 land squarely on §28: a change on the release path with no obtainable CI evidence cannot support any Implemented/Validated claim about the release process itself. That gap is already filed as the §28.2 proposal of 2026-09-02 (gates that cannot fail) and the §28.3 proposal of 2026-09-03 (what tree the check ran against); the "release-only path is never exercised before the release" variant is a narrower case of §28.3's argument and I do not think it earns a separate proposal. No new proposal appended.
Proposed changes
- Hold this PR until
actions/upload-artifactcan move in the same change (finding 1). - Get one execution of the download step on record — throwaway pre-release tag or a
workflow_dispatchbuild-and-download path (finding 2). - Independently, land the
ruffpass onmaster(finding 4) and theci-summaryfix (finding 3), in the order given in the EoSim#21 review.
Of the five open EoSim dependabot PRs, #22 (checkout 4→7) and #23 (scorecard 2.4.3→2.4.4) are the ones to land first; this one should wait for its pair.
Verification I ran
grep -rn "upload-artifact\|download-artifact" .github/workflows/overorigin/master→ uploads atnightly.yml:36,62,weekly.yml:35,62,release.yml:46,69,video-build.yml:80,book-build.yml:224,ci.yml:56,84,209,251, all@v4; downloads atrelease.yml:126,131,206andbook-build.yml:240,284, all bumped to@v8by this diff. This is the evidence for finding 1.- Read
release.yml:40-75,118-140,198-215andbook-build.yml:1-14,218-295fromorigin/master→ confirms the tag-only / release-only / master-push-only gating and thepypa/gh-action-pypi-publishconsumer, which is the evidence for finding 2. - Read the v6.0.0/v7.0.0/v8.0.0 release notes from the PR body for the breaking-change list above.
gh run view --job 99405029320 --log-failed(Lint & Format) and--job 99405029297(Quick Checks) → the ruff violations in finding 4.gh api repos/embeddedos-org/EoSim/branches/master/protection→required_status_checks: null;gh pr view 24 ...→UNSTABLE APPROVED MERGEABLE.
Not checked
- Nothing was executed, and nothing could be. I did not run
download-artifact@v8against a@v4-uploaded artifact. Finding 1's expectation that it works is read from release notes, not observed — that is precisely why finding 2 asks for one real run before merge rather than asserting the bump is broken. - I did not push a tag, dispatch a workflow, or trigger a release. This reviewer does not push.
- I did not check whether EoSim uses self-hosted runners; the Node 24 floor is satisfied by GitHub-hosted runners and unverified for anything else.
- The local EoSim checkout is dirty (179 modified tracked
.pycfiles) and two commits behindorigin/master; the sync step correctly left it alone and everything above was read fromorigin/masterviagit show. I did not stash, reset or check out anything.
Automated architecture review of a0ef1f8ebebc — 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/download-artifact from 4 to 8.
Release notes
Sourced from actions/download-artifact's releases.
... (truncated)
Commits
3e5f45bAdd regression tests for CJK characters (#471)e6d03f6Add a regression test for artifact name + content-type mismatches (#472)70fc10cMerge pull request #461 from actions/danwkennedy/digest-mismatch-behaviorf258da9Add change docsccc058eFix linting issuesbd7976bAdd a setting to specify what to do on hash mismatch and default it toerrorac21fcfMerge pull request #460 from actions/danwkennedy/download-no-unzip15999bfAdd note about package bumps974686eBump the version tov8and add release notesfbe48b1Update test names to make it clearer what they doDependabot 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)