ci: attach constraints via draft-then-publish under immutable releases#519
Open
ian-flores wants to merge 2 commits into
Open
ci: attach constraints via draft-then-publish under immutable releases#519ian-flores wants to merge 2 commits into
ian-flores wants to merge 2 commits into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Adjusts the release/publish workflow split to work with GitHub Immutable Releases by ensuring the constraints asset is attached before a release is published (and thus locked).
Changes:
- Stop
release.yml(semantic-release) from creating a GitHub Release (--no-vcs-release), while still tagging and updatingCHANGELOG.md. - Create the GitHub Release in
publish.ymlas a draft, attachconstraints-<version>.txt, then publish the release. - Reconstruct release notes from the matching
CHANGELOG.mdsection plus a compare-link footer.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| .github/workflows/release.yml | Prevents semantic-release from creating/publishing the GitHub Release so assets can be attached before immutability locks it. |
| .github/workflows/publish.yml | Creates a draft release, attaches the constraints file, builds release notes from CHANGELOG.md, then publishes the release. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+79
to
+83
| gh release create "${GITHUB_REF_NAME}" "constraints-${VERSION}.txt" \ | ||
| --draft \ | ||
| --title "${GITHUB_REF_NAME}" \ | ||
| --notes-file release-notes.md | ||
| gh release edit "${GITHUB_REF_NAME}" --draft=false |
Comment on lines
+59
to
+63
| awk -v tag="v${VERSION}" ' | ||
| $0 ~ "^## " tag "( |$)" {found=1; next} | ||
| found && /^## v/ {exit} | ||
| found {print} | ||
| ' CHANGELOG.md > release-notes.md |
ian-flores
marked this pull request as ready for review
July 21, 2026 22:58
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.
Problem
The
Publish to PyPIworkflow's constraints job fails on every release with:GitHub's Immutable Releases feature is enabled on this repo, so a release's assets are locked the instant it is published. semantic-release created the release (published, not draft) in
release.yml, thenpublish.ymltried togh release uploadtheconstraints-<version>.txtafterward — which is impossible for an immutable release. The retry loop's "release not ready" assumption no longer holds; 422 is permanent, so all 5 attempts fail.PyPI publishing itself was unaffected.
Fix
Move GitHub release creation into the tag-triggered
publish.ymland use the only flow immutable releases support: create as draft → attach the constraints file → publish.release.yml:--vcs-release→--no-vcs-release. semantic-release still bumps the version, writes the changelog, and pushes the tag; it no longer creates the GitHub release.publish.yml: the renamedreleasejob creates the release as a draft with the constraints file attached, then un-drafts it (which locks it immutably, now with the asset baked in). Release notes are reproduced from theCHANGELOG.mdsection plus the compare-link footer, matching the previous--vcs-releasebody.The old tag/release race the retry loop guarded against is gone: nothing creates the release until this job does, after the tag exists.
Notes