Repository navigation
fix(release): commit the standing PR's release branch with the PR title - #729
Merged
Merged
Conversation
Contributor
|
Standing release PR: #730 · v0.42.1 queued (4 packages) · open 5h 54m · ✅ ready to merge Release Preview — v0.42.0 → v0.42.1
These changes will be added to the release PR (#730) when merged: Changelogmonorepo 0.42.0 → 0.42.1
After merge — predicted release
Updated automatically by ReleaseKit |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
GitHub's default squash title for a single-commit PR is the commit's subject, so v0.42.0 landed on main as "chore: release preparation (#614)" instead of "chore: release v0.42.0 (#614)". The release branch's commit now uses the PR title, falling back to the fixed subject when a custom title matches no skip pattern. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A custom standing-PR title carrying a CI-skip marker would otherwise reach the release commit, and a single-commit squash would copy it onto main and skip the publish workflow. Such a title now falls back to the fixed subject. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
goosewobbler
force-pushed
the
fix/release-commit-subject
branch
from
October 23, 2026 18:38
cb56e53 to
9db0382
Compare
Co-authored-by: Cursor <cursoragent@cursor.com>
Owner
Author
|
@greptile review |
A custom title that matches no skip pattern, or carries a CI-skip marker, was silently replaced on both the commit and the PR. The run now warns, and the `title` option's description says when the fallback applies. The commit subject and PR title are one variable again, and one test covers both. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The comment below says the title must match a skip pattern, and the code enforces it, so the note on the default titles repeated it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
goosewobbler
pushed a commit
that referenced
this pull request
Oct 23, 2026
Both PRs added fields at the same spot in setupGit, so whichever merged second conflicted. These seeds now sit elsewhere in the helper. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… safe
The fallback subject was never checked against release.ci.skipPatterns.
With custom or empty patterns, even the default title failed the check
and was replaced by a subject that matched nothing either, so the PR lost
its title and the merge still triggered another standing-PR update.
A title with a CI-skip marker is still always replaced. A title the skip
patterns miss is replaced only when they match the fallback; otherwise
it's kept, with a warning that the merge will trigger another update.
Tests cover custom and empty skip patterns, the warnings, and retitling
an existing standing PR. The ci-setup and release README tables now state
the rule and list ${tag}.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The release-branch commit now carries the standing PR title, which a consumer configures, so a commit-msg hook such as commitlint can reject it. The publish stage's commit already respects git.skipHooks; the standing PR's commit now does too. Unset still runs the hooks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ywhere ci-setup.md said the fallback applied only when the skip patterns match it, but a title with a CI-skip marker is always replaced. The schema description now says which titles are replaced, and both tables name the non-sync default. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…peat Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 24, 2026
Merged
goosewobbler
added a commit
that referenced
this pull request
Oct 24, 2026
… pnpm setup (#753) * fix(ci): standing-PR templates — publish concurrency, LLM on publish, pnpm setup Fixes #739 Co-authored-by: Cursor <cursoragent@cursor.com> * fix(release): guard release branch delete against concurrent updates Co-authored-by: Cursor <cursoragent@cursor.com> * docs(ci): pass LLM provider keys on immediate releases Co-authored-by: Cursor <cursoragent@cursor.com> * fix(ci): give closed-PR runs a group per PR so a queued publish isn't replaced The workflows had gone back to one shared group for push, schedule and merge runs, which is the bug #739 reports: GitHub keeps one pending run per group, so a newer push or schedule run replaced a queued publish. A shared closed-PR group has the same flaw, since an ordinary PR closing could replace it. Events on a closed PR (publish on merge, a retry label) now each get a group per PR. The branch-delete guard already in this PR covers the update that can now run alongside a publish. Also: - troubleshooting.md and the ci-setup troubleshooting row point the LLM key at the publishing jobs, not update-release-pr; - the ci-setup update job lists all three provider keys again; - a test checks the guard still deletes a branch whose tip matches. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(ci): list every job in the standing-PR secrets table The table said "both jobs" for GITHUB_TOKEN and left retry-publish off the NPM_TOKEN row, but the workflow now has four jobs and retry-publish publishes too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(release): move the setupGit ref seeds away from #729's status seed Both PRs added fields at the same spot in setupGit, so whichever merged second conflicted. These seeds now sit elsewhere in the helper. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(release): delete the release branch under a lease The tip check and the delete were separate steps, so an update's force-push landing between them was still deleted, and a failed fetch left the check comparing stale data. Delete with --force-with-lease pinned to the manifest's releaseBranchSha instead, which the remote checks atomically, and keep cleanup errors as warnings so they can't fail a finished publish. Drops Git.resolveRef, which only the old check used, and validates releaseBranchSha in the manifest schema. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ci): stop closed-PR events cancelling or replacing a publish A maintainer's edit on a merged PR landed in the per-PR closed group with cancel-in-progress on, so it cancelled a running publish. Only the publish on merge and the retry label now use that group, events on a closed PR that run no job get a group of their own, and only edits on an open PR cancel. The publish jobs now end with refresh-after-release, so an update that ran during the publish is rebuilt once the tags exist. Also adds the example immediate-release job's .npmrc step, restores the preview-notes keys on the example update job, adds LLM keys to the ci-setup retry job, and brings ci-setup, the example README and the release README's preview snippet in line. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(release): lease the branch delete on the merged PR's head The merged PR's head commit is what was merged, so lease the delete on it instead of a manifest field. That also covers manifests written before this change and a hand push to release/next before the merge. If the head can't be read, or isn't a commit SHA, keep the branch and warn. Adds headSha to the forge's PullRequestDetails and drops the manifest's releaseBranchSha. A null lease no longer crashes the push. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ci): keep immediate releases queued with updates Only the standing PR's own merge and retry runs get a per-PR group. A merged release:immediate PR goes back to the shared group, so it no longer writes release/next at the same time as the update from its own merge. Drops the reconcile step added to the publish jobs: it checks the job's checkout, the tagged merge commit, before fetching main, so it closed a standing PR an update had just opened. The template moves to Node 24 like the example, since OIDC trusted publishing needs a newer npm than Node 22 ships. The npm hints now say to drop pnpm/action-setup, and the retry label notes mention the concurrency group. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(git): refuse a push lease whose expect isn't a commit SHA An empty expect means "only if the ref is absent" to git, and a symbolic one is resolved locally, so either silently changes what the lease checks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ci): keep immediate-release off the standing PR, and tidy hints immediate-release now skips the standing PR itself, so a standing PR carrying release:immediate doesn't publish twice. The npm hints also swap `pnpm exec` for `npx`, the templates say pnpm/action-setup needs a `packageManager` field or a `version`, and deleteBranchOnMerge says when publish keeps the branch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ci): match the standing branch exactly, and harden the lease checks The immediate-release guard and the concurrency group matched any `release/*` head, so a release:immediate hotfix from `release/hotfix-x` was skipped and shipped nothing. Both now match `release/next`, the hardcoded default like the label names. The lease check is shared as isCommitSha from @releasekit/git, a lease the remote refuses mid-update counts as a moved branch rather than a failed delete, and the warning says whether the head was unreadable or not a SHA. The deleteBranchOnMerge: false tests seed a head commit, so they now fail if the flag is ignored. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(release): fall back to the event's head commit for the delete lease If reading the merged PR from GitHub fails, the event payload that triggered the publish already holds the same head commit, so use it rather than keeping the branch. Also treats GitHub's "incorrect old value provided" as a refused lease, not a failed delete. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Description
The standing PR's release branch holds a single commit, always titled
chore: release preparation. With GitHub's default squash setting ("Default message"), a single-commit PR is squashed under that commit's subject rather than the PR title. So 0.42.0 landed onmainaschore: release preparation (#614)rather thanchore: release v0.42.0 (#614). Earlier releases got the PR title only because this repo's squash setting was "Pull request title" until recently.chore: release preparation, on both the commit and the PR, in two cases. The run warns each time, and the option's description says so.main, skipping the publish workflow. Always replaced.release.ci.skipPatternsentry, so the merge would trigger another standing-PR update. Replaced only when the patterns match the fallback; otherwise the title is kept and the warning says the merge will trigger another update.git.skipHooks, as the publish stage's commit already does, so a commit-msg hook such as commitlint can be skipped for a custom title.Related Issue(s)
None; seen on #614's merge.
Type of Change
feat— New featurefix— Bug fixdocs— Documentation changerefactor— Code refactoringtest— Adding or updating testschore— Maintenance, dependencies, toolingScope
@releasekit/version@releasekit/notes@releasekit/publish@releasekit/release@releasekit/config@releasekit/coreChecklist
pnpm lint)pnpm test)pnpm typecheck)Testing Notes
runStandingPRUpdateand check both the release commit's subject and the PR title:chore: release v1.2.3is used as is, with no warning.chore: release preparationreplaces a title that matches no skip pattern, and a title with a CI-skip marker, including when custom skip patterns miss the fallback.git.skipHooksreaches the release commit, set and unset.main'sstanding-pr.ts.pnpm lint, and typecheck and tests for@releasekit/release(864) and@releasekit/config(230), pass.schema:checkanddocs:checkpass.🤖 Generated with Claude Code
The PR appears safe to merge.Summary
The release branch commit now uses the standing PR title when it matches
skipPatternsand contains no CI-skip marker.Reviews (3) · Last reviewed commit: "fix(release): align standing PR title wi..." · Reviewed by Greptile