fix(workflows): use draft-first release flow to avoid immutability errors#554
Conversation
…rors - add draft: true to release-please-config.json so releases start as drafts - create git tag explicitly via API after draft creation (lazy tag workaround) - replace delete/recreate publish step with gh release edit --draft=false - remove bridge step that deleted immutable releases to recreate as drafts 🔧 - Generated by Copilot
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #554 +/- ##
==========================================
- Coverage 85.36% 85.34% -0.03%
==========================================
Files 23 23
Lines 4475 4475
==========================================
- Hits 3820 3819 -1
- Misses 655 656 +1
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR implements a draft-first release flow to resolve persistent HTTP 422 immutability errors that plagued the previous four attempts (PRs #538, #545, #550, #552). The solution leverages GitHub's mutable draft releases: release-please creates releases as drafts, a workaround manually creates git tags (until upstream support for force-tag-creation lands), assets are uploaded to the mutable draft, and finally the draft is published via gh release edit --draft=false.
Changes:
- Added
"draft": truetorelease-please-config.jsonto create mutable draft releases - Replaced the delete-and-recreate release logic with a manual git tag creation workaround for draft releases with lazy tag behavior
- Simplified the publish step from delete-and-recreate to a simple
gh release edit --draft=falsecommand
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
release-please-config.json |
Added "draft": true configuration to create releases as mutable drafts |
.github/workflows/main.yml |
Replaced immutable release deletion logic with manual git tag creation for drafts and simplified publish step to edit draft releases |
🤖 I have created a release *beep* *boop* --- ## [2.3.8](hve-core-v2.3.7...hve-core-v2.3.8) (2026-02-14) ### 🐛 Bug Fixes * **workflows:** use draft-first release flow to avoid immutability errors ([#554](#554)) ([c8eee58](c8eee58)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: hve-core-release-please[bot] <254602402+hve-core-release-please[bot]@users.noreply.github.com>
Pull Request
Description
Fixes the persistent
HTTP 422: tag_name was used by an immutable releaseerror in thepublish-releasejob. This is the fifth iteration (PRs #538 → #545 → #550 → #552) — all previous approaches failed because they attempted to delete and recreate releases or tags after publication, which GitHub's immutability model permanently forbids.Root Cause
GitHub's immutable releases documentation states:
The tag name is permanently tainted at GitHub's infrastructure level once a release is published with immutability enabled. Every delete/recreate approach was fundamentally doomed:
"draft": truein configgh release edit --draft=trueSolution: Draft-First Flow
Follow GitHub's recommended workflow:
"draft": truein config)attest-and-uploadandupload-plugin-packagesjobs)gh release edit --draft=false— release becomes immutable with all assets already attachedDraft Race Condition Workaround
release-please with
"draft": trueuses lazy tag creation — the git tag isn't materialized until publish. Without the tag, release-please's GraphQL query returns null fortagandtagCommit, causing it to skip the draft and propose a bogus version bump.This was fixed upstream in googleapis/release-please#2627 (
force-tag-creationoption), but the fix is not yet released in release-please-action (latest: v4.4.0 → release-please 17.1.3). We work around this by explicitly creating the git tag via API after draft creation.When a new release-please-action ships with PR #2627, replace the manual tag creation step with
"force-tag-creation": trueinrelease-please-config.json.Related Issue(s)
Supersedes PRs #538, #545, #550, #552
Type of Change
Select all that apply:
Code & Documentation:
Infrastructure & Configuration:
Testing
--draft=falseedit (not a delete/create)Checklist
Required Checks
Security Considerations
Additional Notes
release-please-actionincludesforce-tag-creationsupport, the manual tag creation step can be replaced with a single config line. This is documented in a code comment referencing feat: add --force-tag option to explicitly create git tags for releases. googleapis/release-please#2627.