Make Release workflow idempotent via softprops/action-gh-release#34
Closed
Make Release workflow idempotent via softprops/action-gh-release#34
Conversation
The github-release step previously called `gh release create` directly, which fails with HTTP 422 when a release already exists for the tag - the case when a maintainer creates the release through the GitHub UI (which also creates the tag and triggers this workflow). Both v0.1.0 and v0.1.1 hit this and reported red even though PyPI publish succeeded. softprops/action-gh-release updates the existing release instead of failing, so both flows (push-tag-only and create-release-in-UI) now end green. The action talks to the API directly, so the checkout step is no longer needed in this job.
Collaborator
Author
|
Abandoning. The zizmor |
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
The
github-releasestep in.github/workflows/release.ymlcallsgh release createdirectly, which returns HTTP 422 when a release already exists for the tag. This happens whenever a maintainer creates the release through the GitHub UI (orgh release createlocally), since that flow creates the tag and the release in one shot - and the tag push then triggers this workflow, which tries to create the release a second time.Both v0.1.0 (run 25136525282) and v0.1.1 (run 25227782847) hit this. PyPI publishing succeeded both times; only the final release-creation step failed, leaving the run red.
This PR swaps the raw
gh release createforsoftprops/action-gh-release, which is idempotent: per its README, "if a tag already has a GitHub release, the existing release will be updated." Both flows (push-tag-only and create-release-in-UI) now end green.The action talks to the GitHub API directly, so the
actions/checkoutstep is no longer needed in this job and was removed.Pinned to v3.0.0 SHA (
b4309332981a82ec1c5618f44dd2e27cc8bfbfda) to match the repo's pinning convention; Dependabot's existing weeklygithub-actionsgroup will keep it current.Note: zizmor emits one informational
superfluous-actionsfinding on the new step (it advisesgh releaseis built into the runner). That's purely stylistic and does not fail CI - we accept it in exchange for idempotency, which the built-ingh release createdoes not provide.Test plan
uvx zizmor .github/workflows/shows only the one expected informational finding, no warnings/errorsAudit workflowsjob passes on this PRgithub-releasejob succeeds whether the release already exists or not (verifiable on the next real release; can also be smoke-tested by re-runningReleaseforv0.1.1after merge - the existing release should be updated rather than recreated)Important
Most code in
ionq_core/is auto-generated and overwritten on regeneration.See CONTRIBUTING.md for which files are safe to edit.