fix(ci): pin checkout SHA + PEP 440 versions#225
Merged
Conversation
Two follow-ups to #222: - release-go.yml validate + publish, release-typescript.yml validate + publish, and release-python.yml build all `actions/checkout@v4` with `ref: main`. Between validate and post-approval publish, main can advance and publish would build a different SHA than validate verified. Pin every checkout to `${{ github.sha }}` so a single dispatch invocation always operates on one commit. - The Python release workflow's regex `^[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.-]+)?$` rejects PEP 440 canonical prereleases (`0.2.0rc1`, `0.2.0.dev0`) while still accepting PyPI-invalid forms like `0.2.0-dev`. Replaced with packaging.version.Version that requires the input to be in PEP 440 canonical form (so `0.2.0-rc.1` and `0.2.0-dev` are also rejected, since they normalise to something the operator did not type and would silently disagree with pyproject.toml). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
36 tasks
NikolayS
added a commit
that referenced
this pull request
May 7, 2026
Surfaced by the v0.2.0-rc.1 dry-run: npm refuses to publish a prerelease without an explicit dist-tag, because otherwise the prerelease would silently inherit the `latest` tag and `npm install pgque` would resolve to it for every user. Resolve the dist-tag from the version's prerelease identifier: 0.2.0 -> latest 0.2.0-rc.1 -> rc 0.2.0-dev.0 -> dev 0.2.0-beta.3 -> beta 0.2.0-alpha.1 -> alpha 0.2.0-anything -> next (catch-all) Apply in both the validate-stage `npm publish --dry-run --provenance` and the gated `npm publish --provenance` step. Caught by the post-#225 dry-run that ran end-to-end for the first time. Co-authored-by: Claude Opus 4.7 (1M context) <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
1 participant
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.
Summary
Two real follow-ups to #222 surfaced by review:
High — Go publish TOCTOU (and the same class in TS)
release-go.yml'svalidateandpublishjobs bothactions/checkout@v4withref: main. Between validate finishing andpublishrunning after thego-releaseenvironment approval, main can advance — and the post-approval publish builds a different SHA than the one validate verified. Same pattern inrelease-typescript.yml(validate + publish, gated by thenpmenvironment).Fix: pin every
actions/checkout@v4in all three release workflows toref: ${{ github.sha }}so a single workflow_dispatch invocation always operates on one commit. The Python workflow'sbuildjob is also pinned for consistency, even thoughpublish-{testpypi,pypi}download the validated artifact rather than re-checkout.Medium — Python regex rejects PEP 440 canonical, accepts PyPI-invalid
release-python.yml:48regex^[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.-]+)?\$(pre-fix) silently misclassifies versions:0.2.0rc10.2.0.dev00.2.0-rc.10.2.0rc1)0.2.0-dev0.2.0.dev0)Replaced with
packaging.version.Version(...)that requires the input to be in PEP 440 canonical form. This forces operators to type exactly the string that ends up in pyproject.toml and on PyPI — no silent normalisation surprise where the dispatch input disagrees with what gets published.Validation
actionlintclean on all three workflows.Test plan
Related
🤖 Generated with Claude Code