Skip to content

chore(deps): bump actions/download-artifact from 4.1.4 to 8.0.1 - #28

Open
dependabot[bot] wants to merge 3 commits into
release/v0.0.2-rcfrom
dependabot/github_actions/actions/download-artifact-8.0.1
Open

chore(deps): bump actions/download-artifact from 4.1.4 to 8.0.1#28
dependabot[bot] wants to merge 3 commits into
release/v0.0.2-rcfrom
dependabot/github_actions/actions/download-artifact-8.0.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 10, 2026

Copy link
Copy Markdown

Bumps actions/download-artifact from 4.1.4 to 8.0.1.

Release notes

Sourced from actions/download-artifact's releases.

v8.0.1

What's Changed

Full Changelog: actions/download-artifact@v8...v8.0.1

v8.0.0

v8 - What's new

[!IMPORTANT] actions/download-artifact@v8 has been migrated to an ESM module. This should be transparent to the caller but forks might need to make significant changes.

[!IMPORTANT] Hash mismatches will now error by default. Users can override this behavior with a setting change (see below).

Direct downloads

To support direct uploads in actions/upload-artifact, the action will no longer attempt to unzip all downloaded files. Instead, the action checks the Content-Type header ahead of unzipping and skips non-zipped files. Callers wishing to download a zipped file as-is can also set the new skip-decompress parameter to true.

Enforced checks (breaking)

A previous release introduced digest checks on the download. If a download hash didn't match the expected hash from the server, the action would log a warning. Callers can now configure the behavior on mismatch with the digest-mismatch parameter. To be secure by default, we are now defaulting the behavior to error which will fail the workflow run.

ESM

To support new versions of the @actions/* packages, we've upgraded the package to ESM.

What's Changed

Full Changelog: actions/download-artifact@v7...v8.0.0

v7.0.0

v7 - What's new

[!IMPORTANT] actions/download-artifact@v7 now runs on Node.js 24 (runs.using: node24) and requires a minimum Actions Runner version of 2.327.1. If you are using self-hosted runners, ensure they are updated before upgrading.

Node.js 24

This release updates the runtime to Node.js 24. v6 had preliminary support for Node 24, however this action was by default still running on Node.js 20. Now this action by default will run on Node.js 24.

What's Changed

... (truncated)

Commits
  • 3e5f45b Add regression tests for CJK characters (#471)
  • e6d03f6 Add a regression test for artifact name + content-type mismatches (#472)
  • 70fc10c Merge pull request #461 from actions/danwkennedy/digest-mismatch-behavior
  • f258da9 Add change docs
  • ccc058e Fix linting issues
  • bd7976b Add a setting to specify what to do on hash mismatch and default it to error
  • ac21fcf Merge pull request #460 from actions/danwkennedy/download-no-unzip
  • 15999bf Add note about package bumps
  • 974686e Bump the version to v8 and add release notes
  • fbe48b1 Update test names to make it clearer what they do
  • Additional commits viewable in compare view

Dependabot compatibility score

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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will 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 version will 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 dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

n1ckyb and others added 3 commits August 8, 2026 04:23
Work targets a release-candidate branch, never main. main only moves when the RC is released, so a merge cannot accidentally become one.
Work targets a release-candidate branch, never main. main only moves when the RC is released, so a merge cannot accidentally become one.
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4.1.4 to 8.0.1.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](actions/download-artifact@c850b93...3e5f45b)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-version: 8.0.1
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot @github

dependabot Bot commented on behalf of github Aug 10, 2026

Copy link
Copy Markdown
Author

Labels

The following labels could not be found: dependencies, github-actions. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

@n1ckyb
n1ckyb changed the base branch from main to release/v0.0.2-rc August 10, 2026 16:54
n1ckyb pushed a commit that referenced this pull request Aug 10, 2026
The first commit on this branch fixed two pin comments. Auditing every pin against
the real upstream tag lists found five, not two:

    actions/checkout@3d3c42e5        said v4.2.2      really v7.0.1   (ci.yml AND publish.yml)
    actions/upload-artifact@043fb46d said v4.5.0      really v7.0.1
    actions/download-artifact@3e5f45 said v4.1.4      really v8.0.1
    pypa/gh-action-pypi-publish@dc37 said release/v1  really v1.14.2

The last is not a lie - naming the branch is a legitimate convention, and
dtolnay/rust-toolchain@... # stable is left exactly as it is for that reason. But
it leaves Dependabot no version to compare against, which is why it keeps
proposing 1.14.2 over a pin that already IS 1.14.2 (#30).

All five share one signature: a bump replaced the SHA and left the comment behind.
Nothing in CI could see it, because a stale comment is still valid YAML and the
workflow runs perfectly - just not the version everyone believes it runs.

WHY THIS IS NOT COSMETIC

The comment is the only human-readable part of a SHA pin. Wrong, it breaks three
things at once:

  - Reviewers approve a version they were never shown. The diffs above understate
    what runs by three and four major versions.
  - Dependabot proposes bumps that are already applied, because it trusts the
    comment. #27, #28, #30 and #31 are all CONFLICTING or failing for this reason
    and this reason alone.
  - "Pin to SHA" stops buying anything if nobody can tell which release the SHA
    is, and the label they use to tell is wrong.

THE GATE

Fixing five comments without adding a check just resets the clock, so:

  scripts/check_action_pin_comments.py resolves every pinned SHA against the
  upstream tag list and fails on disagreement. It reads only public tags, so
  GITHUB_TOKEN suffices and it runs on Dependabot and fork PRs - the PRs where
  this symptom actually surfaces. Comments naming a branch are reported, not
  failed.

  tests/unit/test_action_pin_comments.py checks offline what can be checked
  offline: no bare SHAs, one SHA never labelled two versions, one version label
  never pointing at two SHAs, nothing pinned to a mutable ref.

Both were verified to BITE, not just to pass: reintroducing the v4.2.2 comment
makes the script exit 1 with the mismatch named, and fails the offline test that
one SHA carries two labels. Clean, the script reports 13 pins agreeing and 0
disagreeing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
n1ckyb added a commit that referenced this pull request Aug 10, 2026
* fix(ci): correct action version comments that disagreed with their SHAs

publish.yml pinned:

    actions/upload-artifact@043fb46d... # v4.5.0     <- SHA is v7.0.1
    actions/download-artifact@3e5f45b2... # v4.1.4   <- SHA is v8.0.1

Confirmed against the upstream tag lists. The SHAs are correct and were verified
when they landed; the COMMENTS were not updated with them.

My fault. Rebuilding those Dependabot branches on the RC replaced the pinned SHA
and left the trailing comment untouched, so every reader of this workflow has
since been told it runs v4.5.0 while it actually runs v7.0.1 - a three-major gap
in what a reviewer thinks they are approving.

The comment is the ONLY human-readable part of a SHA pin. A wrong one is worse
than none: it looks like provenance and is misinformation.

It also explains why Dependabot #27 and #28 CONFLICT. Dependabot reads the
comment, believes the pin is v4.5.0, and proposes bumping to the SHA that is
already there. With the comments corrected those PRs are redundant rather than
conflicting - they propose exactly what is already pinned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(ci): correct all five lying action pins, and gate against a sixth

The first commit on this branch fixed two pin comments. Auditing every pin against
the real upstream tag lists found five, not two:

    actions/checkout@3d3c42e5        said v4.2.2      really v7.0.1   (ci.yml AND publish.yml)
    actions/upload-artifact@043fb46d said v4.5.0      really v7.0.1
    actions/download-artifact@3e5f45 said v4.1.4      really v8.0.1
    pypa/gh-action-pypi-publish@dc37 said release/v1  really v1.14.2

The last is not a lie - naming the branch is a legitimate convention, and
dtolnay/rust-toolchain@... # stable is left exactly as it is for that reason. But
it leaves Dependabot no version to compare against, which is why it keeps
proposing 1.14.2 over a pin that already IS 1.14.2 (#30).

All five share one signature: a bump replaced the SHA and left the comment behind.
Nothing in CI could see it, because a stale comment is still valid YAML and the
workflow runs perfectly - just not the version everyone believes it runs.

WHY THIS IS NOT COSMETIC

The comment is the only human-readable part of a SHA pin. Wrong, it breaks three
things at once:

  - Reviewers approve a version they were never shown. The diffs above understate
    what runs by three and four major versions.
  - Dependabot proposes bumps that are already applied, because it trusts the
    comment. #27, #28, #30 and #31 are all CONFLICTING or failing for this reason
    and this reason alone.
  - "Pin to SHA" stops buying anything if nobody can tell which release the SHA
    is, and the label they use to tell is wrong.

THE GATE

Fixing five comments without adding a check just resets the clock, so:

  scripts/check_action_pin_comments.py resolves every pinned SHA against the
  upstream tag list and fails on disagreement. It reads only public tags, so
  GITHUB_TOKEN suffices and it runs on Dependabot and fork PRs - the PRs where
  this symptom actually surfaces. Comments naming a branch are reported, not
  failed.

  tests/unit/test_action_pin_comments.py checks offline what can be checked
  offline: no bare SHAs, one SHA never labelled two versions, one version label
  never pointing at two SHAs, nothing pinned to a mutable ref.

Both were verified to BITE, not just to pass: reintroducing the v4.2.2 comment
makes the script exit 1 with the mismatch named, and fails the offline test that
one SHA carries two labels. Clean, the script reports 13 pins agreeing and 0
disagreeing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: n1ckyb <nicknuxton@icloud.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant