ci: harden protected-branch release workflow - #11
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 13fc9ded2c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| git ls-remote --exit-code --tags | ||
| "https://github.com/${GITHUB_REPOSITORY}.git" | ||
| "refs/tags/${RELEASE_TAG}" |
There was a problem hiding this comment.
When a maintainer creates a matching v* tag on an unmerged topic-branch commit whose package version matches, this validation only proves that the tag exists remotely; the subsequent checkout, build, and publish all accept it. The workflow can therefore release code that bypassed the newly documented pull-request and required-CI process. Resolve the tag commit and verify that it is the intended commit on origin/main before starting the platform builds.
Useful? React with 👍 / 👎.
| contents: read | ||
|
|
||
| concurrency: | ||
| group: release-${{ inputs.tag || github.ref }} |
There was a problem hiding this comment.
For the same tag, a tag-push run uses a key such as release-refs/tags/v0.4.4, while a manual-dispatch run uses release-v0.4.4. If a manual retry is started while the push-triggered release is still running, GitHub places them in different concurrency groups, so both can pass the initial nonexistence check and race at release creation instead of being serialized as documented. Build the key from the normalized tag name for both event types.
Useful? React with 👍 / 👎.
| if gh release view "$RELEASE_TAG" --repo "$GITHUB_REPOSITORY" >/dev/null 2>&1; then | ||
| echo "release ${RELEASE_TAG} already exists" >&2 | ||
| exit 1 |
There was a problem hiding this comment.
If gh release create fails while uploading an asset or publishing, it can leave a draft release for the tag, after which the documented manual retry always exits here instead of recovering it. This follows from gh release create --help, which states that separate API calls create a draft, upload the assets, and then publish it. Distinguish a published release from an incomplete draft and resume or explicitly replace the latter so the retry path works after partial publication failures.
Useful? React with 👍 / 👎.
|
pass |
1 participant
Summary / 变更说明
.vscode/files.Validation / 验证
cargo fmt -- --checkcargo test --lockedcargo clippy --all-targets --all-features -- -D warningscargo build --locked --releasecargo deny --offline check advisories bans licenses sourcesgit diff --checkRisk and rollback / 风险与回滚
Risk is limited to GitHub Actions scheduling and release gating. Release runs now require an existing remote tag and stop before platform builds when the tag, version, or existing Release state is invalid. No repository contents, manifests, locking, Git history, or platform scheduler behavior is changed.
Rollback by reverting commit
13fc9de; the separate.gitignorecommit can remain independently.