Repository navigation
ci: publish to pypi before uploading the release asset - #4996
Merged
kddejong merged 1 commit intoNov 5, 2026
Merged
Conversation
The sdist upload ran between the build and the publish step, so a GitHub API failure stopped the release from reaching PyPI. Publishing is the irreversible step, so it now runs first and a problem attaching the asset can no longer block it. Add --clobber to gh release upload so a re-run after a partial failure is idempotent instead of failing on the asset already present. Pin pypa/gh-action-pypi-publish to the v1.14.3 commit. release/v1 is a branch that moves on every PyPA release, and this job holds id-token: write for trusted publishing. Follow-up to aws-cloudformation#4990.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4996 +/- ##
=======================================
Coverage 94.81% 94.81%
=======================================
Files 441 441
Lines 16179 16179
Branches 3137 3137
=======================================
Hits 15340 15340
Misses 463 463
Partials 376 376
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Description of changes:
Follow-up to #4990, which added the release-tag check and attached the source distribution to stable GitHub releases. Three adjustments to
cd-pypi.yaml.1. Publish to PyPI before uploading the release asset.
As merged, the upload step sits between
Build distributionsandPublish to PyPI, so any failure attaching the asset fails the job and the release never reaches PyPI. Publishing is the irreversible step, so it now runs first and a GitHub-side problem can no longer block it.2.
--clobberongh release upload.Without it, a workflow re-run after a partial failure fails again on the asset already attached — exactly the situation a re-run is meant to recover from.
gh release upload --helpdocuments--clobberas "Delete and re-upload existing assets of the same name".3. Pin
pypa/gh-action-pypi-publish.release/v1is a branch, so it moves on every PyPA release, and this job holdsid-token: writefor trusted publishing pluscontents: writefor the asset upload. Pinned to7245906fb61fa33a13554f9d5fb856fe61758086, the commitv1.14.3dereferences to. Dependabot already tracksgithub-actionsweekly, so the pin will be kept current.First-party
actions/checkoutandactions/setup-pythonare deliberately left on their major tags — the trust boundary for those is GitHub itself, which already owns the runner and the token service, so a pin defends against nothing.Evidence and verification:
The workflow only fires on
release: publishedin this repository, so no CI run exercises it and the first real execution is a live release. Verified what can be verified locally:… Build distributions → Determine release stability → Publish to PyPI → Upload stable source distribution, confirmed by parsing the YAML.bash -nclean on all fiverun:blocks.gh release upload v1.59.0 dist/cfn_lint-1.59.0.tar.gz --repo aws-cloudformation/cfn-lint --clobber.dist/holding one sdist plus one wheel.v1.14.3^{}resolves to7245906fb61fa33a13554f9d5fb856fe61758086viagit ls-remote.pre-commit run --all-files— all hooks pass.pytest test/unit— 3407 passed.What is unchanged:
The release-tag validation and stability-classification logic is untouched, including its position relative to the build. Its body was re-run against 13 tag/version combinations and behaves as merged: correct on every stable case, hard-fails on a tag mismatch or an unreadable version. A sweep of all 190
v1.*tags againstsrc/cfnlint/version.pyat each tagged commit found 165 stable tags with zero mismatches, so the guard changes nothing for a normal release.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.