Skip to content

chore(deps): bump actions/checkout from 4.2.2 to 7.0.1 - #31

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/github_actions/actions/checkout-7.0.1
Open

chore(deps): bump actions/checkout from 4.2.2 to 7.0.1#31
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/github_actions/actions/checkout-7.0.1

Conversation

@dependabot

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

Copy link
Copy Markdown

Bumps actions/checkout from 4.2.2 to 7.0.1.

Release notes

Sourced from actions/checkout's releases.

v7.0.1

What's Changed

Full Changelog: actions/checkout@v7...v7.0.1

v7.0.0

What's Changed

New Contributors

Full Changelog: actions/checkout@v6.0.3...v7.0.0

v6.1.0

What's Changed

https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/ for more details about this breaking change

Full Changelog: actions/checkout@v6.0.3...v6.1.0

v6.0.3

What's Changed

New Contributors

Full Changelog: actions/checkout@v6...v6.0.3

v6.0.2

What's Changed

... (truncated)

Changelog

Sourced from actions/checkout's changelog.

Changelog

v7.0.1

v7.0.0

v6.0.3

v6.0.2

v6.0.1

v6.0.0

v5.0.1

v5.0.0

v4.3.1

v4.3.0

v4.2.2

v4.2.1

... (truncated)

Commits

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)

Bumps [actions/checkout](https://github.com/actions/checkout) from 4.2.2 to 7.0.1.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@11bd719...3d3c42e)

---
updated-dependencies:
- dependency-name: actions/checkout
  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 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.

0 participants