ci: maintain a rolling draft release PR - #753
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 982ece706d
ℹ️ 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".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7475203b03
ℹ️ 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".
|
Codex Review: Didn't find any major issues. Bravo. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
|
Final validation for |
mldangelo
left a comment
There was a problem hiding this comment.
Reviewed the full diff, ran the suite (48 pass), prettier and actionlint clean, and probed runtime behavior with this PR's own test harness.
The harness is unusually strong — real temporary git repos plus a fake GitHub that actually rejects non-fast-forwards and asserts force: false, so the append-only claim is genuinely tested. markdownText holds up against a hostile PR title, the RELEASE_PR_DRY_RUN expression is correct in all four event/var combinations and fails safe, and comparing branch package.json against the merge base minus the version key is a clean way to detect human edits.
Two things I'd want resolved before setting RELEASE_PR_ENABLED: the branch-edit guard turns node-release-pr permanently red on main for a documented maintainer action, and every push to main triggers a fresh @codex review even when the proposal is byte-identical. The rest are simplifications and small hardening notes. Details inline.
| const block = notes === null ? null : findSection(notes, id); | ||
| const humanOwned = | ||
| previous?.reset !== true && | ||
| (previous?.humanOwned !== false || |
There was a problem hiding this comment.
previous?.humanOwned !== false treats absent the same as human-owned — and then writes that back — so a section id missing from a saved state is locked human-owned forever. Verified it survives reruns.
Only bites if sectionIds gains an entry mid-cycle, in which case the new section would never be generated on any existing branch. previous === undefined probably wants to fall through to the generate path rather than join the sticky one.
|
Note To use Codex here, create an environment for this repo. |
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
Summary
Release proposals are currently assembled by hand, so later merges can leave the proposed version and notes out of date. Maintain one draft release PR per cycle while preserving maintainer edits and the human release decision.
Changes
main. Before 1.0, ordinary changes, including features, bump the patch; explicitly marked breaking changes bump the minor. Release PRs use the repository's squash merge flow, and a new empty draft can open after the preceding version bump merges.Testing
eef0e82c, seed12345: 2,152 passed, 43 skipped, zero failures.eef0e82creported no major issues; the security review also completed.Risk and rollout
This does not change the public CLI, enable automated writes, merge a release PR, or publish a package. Existing publication gates remain in place. Breaking-change detection uses commit/PR metadata, and generated notes still need maintainer review. Ready proposals are frozen; if main advances before merge, return the proposal to draft and rerun the updater. Before marking it ready again, check CI and request a final Codex review if the last review targets an older head.
Missing note-ownership metadata deliberately continues to preserve existing text. An explicit section reset resumes generation; absence of state does not authorize overwriting manual notes. If GitHub has not exposed an updated PR head, a manual rerun can post deferred feedback after the head catches up.
The GitHub App write path has been exercised with serialized API fixtures, but has not been run on a hosted workflow. After merging, configure the repository-scoped App, run a manual write pilot with automatic updates disabled, and verify its draft, CI, and Codex review before enabling push-triggered writes. The existing manual release PR is left untouched.
Public disclosure review