chore(deps): bump pypa/gh-action-pypi-publish from 1.14.0 to 1.14.2 - #30
Open
dependabot[bot] wants to merge 1 commit into
Open
chore(deps): bump pypa/gh-action-pypi-publish from 1.14.0 to 1.14.2#30dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [pypa/gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) from 1.14.0 to 1.14.2. - [Release notes](https://github.com/pypa/gh-action-pypi-publish/releases) - [Commits](pypa/gh-action-pypi-publish@cef2210...dc37677) --- updated-dependencies: - dependency-name: pypa/gh-action-pypi-publish dependency-version: 1.14.2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps pypa/gh-action-pypi-publish from 1.14.0 to 1.14.2.
Release notes
Sourced from pypa/gh-action-pypi-publish's releases.
... (truncated)
Commits
dc37677Merge pull request #417 from trail-of-forks/ft/bump-deps8b2f234Bumppypi-attestationsandsigstore78b72dbMerge pull request #416 from takluyver/twine-v792f4d2aUpdate twine to v7ba38be9Merge pull request #408 from adisivaprasad/bump-setup-python-v6a6c5088Bump actions/setup-python from v5.6.0 to v6.2.0Dependabot 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)