Repository navigation
fix(ci): standing-PR templates — publish concurrency, LLM on publish, pnpm setup - #753
Merged
Merged
Conversation
… pnpm setup Fixes #739 Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
|
Standing release PR: #730 · v0.42.1 queued (4 packages) · open 9h 25m · ✅ 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 |
Co-authored-by: Cursor <cursoragent@cursor.com>
Owner
Author
|
@greptile review |
Co-authored-by: Cursor <cursoragent@cursor.com>
Owner
Author
|
@greptile review |
… 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Merged
30 tasks
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.
Fixes #739
release:immediatePR stays in the shared group with the updates, so the two don't writerelease/nextat once. Other events on a closed PR run no job, so each gets a group of its own. Only a maintainer's edit on an open PR cancels.--force-with-leasepinned to the merged PR's head commit, so the remote refuses the delete if an update has force-pushed it since. If the head can't be read, publish keeps the branch and warns. Cleanup errors stay warnings.GitPushOptions.forceWithLeaseaccepts a{ ref, expect }lease, and the forge'sPullRequestDetailscarriesheadSha.immediate-releaseadded to the ci-setup snippet and the example, reconciling withrefresh-after-release.update-release-prneeds one only forrelease:preview-notes. Docs and troubleshooting say so.pnpm/action-setup.immediate-releaseskips the standing PR itself (headrelease/next, hardcoded like the label names), so a standing PR carryingrelease:immediatedoesn't publish twice. The in-step check for a renamed branch is Release gate: a merged standing PR carrying release:immediate is released twice #792.immediate-releasejob removes the token.npmrclike its other publish jobs (whether that step is needed at all is Examples: drop therm -f .npmrcstep, which deletes the repo's own .npmrc rather than setup-node's #791). The ci-setup and example README text matches the new jobs.deleteBranchOnMerge's description says when publish keeps the branch.The standing PR's publish and updates no longer wait for each other, so an update during a publish can double-bump until the next update. Tracked in #790.
Made with Cursor
The PR still needs changes before merging because branch cleanup can race an update and pending releases can still be dropped.
Summary
Updates the standing-PR workflows and adds a branch-tip check before publish cleanup.
Diagram
%%{init: {'theme': 'neutral'}}%% flowchart TD A[Update release branch] --> B[Commit and push] B --> C[Read releaseBranchSha] C --> D[Save manifest in PR comment] D --> E[Publish from manifest] E --> F[Fetch origin] F --> G{Fetched tip matches saved SHA?} G -->|No| H[Keep branch] G -->|Yes| I[Push branch deletion]Reviews (2) · Last reviewed commit: "fix(release): guard release branch delet..." · Reviewed by Greptile