Repository navigation
Require reviewed notes and latest main for releases - #2507
Conversation
![chatgpt-codex-connector[bot]](/p/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: f74aa83eeb
ℹ️ 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".
|
|
||
| These gates apply even when the user initially asks to create or publish a release and supplies the version. | ||
|
|
||
| 1. **Start from freshly fetched main.** Before choosing the release range, generating notes, or selecting a target SHA, run `git fetch origin --prune --tags`. Stop if the fetch fails. Resolve the release endpoint from `refs/remotes/origin/main`; never use the current checkout, local `main`, `HEAD`, a previously cached `origin/main`, or an older commit merely because it is already available locally. |
There was a problem hiding this comment.
In clones whose remote.origin.fetch is restricted to another branch, git fetch origin --prune --tags can succeed without updating refs/remotes/origin/main, because Git uses the configured fetch refspec when none is supplied; if an older origin/main ref is present, both gates silently accept that cached SHA and can publish a stale release. Fetch refs/heads/main:refs/remotes/origin/main explicitly before resolving the endpoint.
Useful? React with 👍 / 👎.
| 2. **Show the exact notes and stop.** Present the complete release notes to the user in a markdown code block, then end the turn without creating a tag, draft release, or published release. The initial release request, a supplied version, or approval of the production-deployment side effect does not approve unseen release notes. Only a subsequent user message approving the displayed notes authorizes publication. | ||
| 3. **Re-fetch immediately before publication.** After the notes are approved and immediately before creating the tag or GitHub release, run `git fetch origin --prune --tags` again and resolve `refs/remotes/origin/main` again. Stop if the fetch fails. | ||
| 4. **Invalidate approval when main moves.** Compare the freshly fetched `origin/main` SHA with the SHA used for the approved release range. If they differ, do not publish. Inspect the new commits, regenerate the notes, show the revised notes, and wait for a new subsequent approval. | ||
| 5. **Target and verify latest main.** Create the release with the exact SHA from the final successful fetch, for example `gh release create <tag> --target <sha> --notes-file <file>`. After creation, verify that the release tag resolves to that SHA. Do not claim success if the target verification fails. |
There was a problem hiding this comment.
When the requested tag already exists remotely but has no release and points to a different commit, this command publishes the release against that existing tag before the post-creation verification detects the mismatch. gh release create --help states that --target controls automatic tag creation when a matching tag does not yet exist, so it does not retarget an existing tag; verify the remote tag first, or create and push the exact tag and use --verify-tag, to avoid publishing a release for the wrong commit.
Useful? React with 👍 / 👎.
|
Summary
Why
Prevents an initial release request from being treated as approval of unseen notes and prevents releases from targeting stale local main state.
Verification
Breaking changes
None.