Skip to content

chore(deps): bump actions/upload-artifact from 4.5.0 to 7.0.1 - #27

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

chore(deps): bump actions/upload-artifact from 4.5.0 to 7.0.1#27
dependabot[bot] wants to merge 3 commits into
release/v0.0.2-rcfrom
dependabot/github_actions/actions/upload-artifact-7.0.1

Conversation

@dependabot

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

Copy link
Copy Markdown

Bumps actions/upload-artifact from 4.5.0 to 7.0.1.

Release notes

Sourced from actions/upload-artifact's releases.

v7.0.1

What's Changed

Full Changelog: actions/upload-artifact@v7...v7.0.1

v7.0.0

v7 What's new

Direct Uploads

Adds support for uploading single files directly (unzipped). Callers can set the new archive parameter to false to skip zipping the file during upload. Right now, we only support single files. The action will fail if the glob passed resolves to multiple files. The name parameter is also ignored with this setting. Instead, the name of the artifact will be the name of the uploaded file.

ESM

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

What's Changed

New Contributors

Full Changelog: actions/upload-artifact@v6...v7.0.0

v6.0.0

v6 - What's new

[!IMPORTANT] actions/upload-artifact@v6 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. v5 had preliminary support for Node.js 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

Full Changelog: actions/upload-artifact@v5.0.0...v6.0.0

v5.0.0

What's Changed

... (truncated)

Commits
  • 043fb46 Merge pull request #797 from actions/yacaovsnc/update-dependency
  • 634250c Include changes in typespec/ts-http-runtime 0.3.5
  • e454baa Readme: bump all the example versions to v7 (#796)
  • 74fad66 Update the readme with direct upload details (#795)
  • bbbca2d Support direct file uploads (#764)
  • 589182c Upgrade the module to ESM and bump dependencies (#762)
  • 47309c9 Merge pull request #754 from actions/Link-/add-proxy-integration-tests
  • 02a8460 Add proxy integration test
  • b7c566a Merge pull request #745 from actions/upload-artifact-v6-release
  • e516bc8 docs: correct description of Node.js 24 support in README
  • 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/upload-artifact](https://github.com/actions/upload-artifact) from 4.5.0 to 7.0.1.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](actions/upload-artifact@6f51ac0...043fb46)

---
updated-dependencies:
- dependency-name: actions/upload-artifact
  dependency-version: 7.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:53
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