[sentry-junior]

@sentry/api releases have gotten stuck in two ways. This PR changes Release, and the Release pipeline health workflow from #138, so neither needs a person to fix it.

Incident 1: commits stranded during a pending release. The old job guard skipped every release merge. A commit that landed while a release was pending was never released until someone pushed again. In the last 40 release merges, 9 brought in commits like this. 83a2b74 is the latest.

Incident 2: a failed release blocked all later ones (11-07 to 11-09). Release ran even when Build failed. It cut release/1.52.0, Build failed on that branch, and every later Release run failed with craft's Release branch "release/1.52.0" already exists until someone cleaned up by hand.

Changes

Release (release.yml):

• Runs on workflow_run after Build succeeds on main (push builds from this repo only). It checks out that commit and puts a local main on it, because craft prepares from the default branch.
• Drops the commit-message guard, so release merges run too. That run is what releases commits that landed while the previous release was pending.
• concurrency: { group: release, cancel-in-progress: false }.
• workflow_dispatch works as before and skips preflight.

release-preflight.sh skips the three cases where craft prepare would fail:

• A release/* branch exists: "release branch already exists". The merge of that release releases what's left.
• The commit predates the newest tag, because Builds finished out of order: craft would cut that version again.
• No commits since the last tag: "no commits found since the last release".

Release pipeline health (release-pipeline-health.yml):

• When Build fails on release/**, drop-failed-release.sh deletes the branch, using --force-with-lease on the failed commit. It then tries to close the getsentry/publish request with a "Superseded" comment. If the bot can't list or close that request, the job logs a warning and still succeeds, because the branch is already gone. If the branch is already gone or has moved since the failed Build (a rerun, or a new push), the job logs "nothing to drop" and passes (f62189b). The next push to main releases again.
• Release-branch Build failures are reported to the pipeline issue too.
• The issue closes only when a Release run's Prepare release step succeeds. A skipped run also finishes as a success, so it no longer closes an open alert. This needs actions: read.
• Concurrency moved to the two jobs that write the issue, so a waiting branch drop can't be cancelled.

Testing

• Preflight and drop script, under dash: I used throwaway git remotes that mirror craft and publish (release branch, tag, merge), with gh stubbed.
  • The stranded commit (83a2b74 model) skips while 1.2.0 is pending, and is released by the merge commit's run.
  • Two syncs in order: A releases, B waits, and the merge releases B.
  • B's Build first: B covers both, A skips, and a late run for A skips.
  • A release merge with nothing new skips.
  • Incident 2: the fix's Release skips while the failed branch exists. After the drop, it releases both commits.
  • Drop edge cases: the branch moved, or it's already gone (the job logs "nothing to drop", passes, and leaves the branch and the request alone); no open request; the issue lookup or close fails (warning, branch still deleted).
• Pipeline issue: with real Release run 42666230595, which prepared a release, the issue closes. With Prepare release skipped, it stays open.
• Live, read-only: preflight on today's main skips because release/1.56.0 is pending.
• craft: earlier, craft prepare --dry-run (3.9.0) from this checkout shape would have cut release/1.53.0 with 83a2b74.
• actionlint and shellcheck --shell=sh --enable=check-extra-masked-returns pass.

No UI changes, so no screenshots.

For admins

• drop-failed-release uses the release bot app (SENTRY_RELEASE_BOT_*). It needs to delete branches here, which it can already do since it pushes them. Closing getsentry/publish issues is optional: without triage access there, the job warns and the request stays open.

via @BYK.

--

View Session in Sentry

[cursor]

Stale Bugbot comment from a previous run.

[BYK]

Since this is an auto-release repo can we not merge the behaviors with #138 and this and automatically delete the release branch when it fails instead? Looks simpler to me?

[cursor]

Stale Bugbot comment from a previous run.

[sentry-junior]

Yes, that's simpler. Done in c24715f:

• When Build fails on release/**, release-pipeline-health.yml now closes the getsentry/publish request with a "Superseded" comment and deletes the branch. The delete is guarded by --force-with-lease on the failed commit and skips versions that are already tagged. The next push to main re-releases, and the failure goes to the pipeline issue.
• Preflight no longer scans branches or searches publish issues. It only checks the newest tag, unreleased commits and any pending release/* branch.
• I moved concurrency to the jobs that write the issue, so a queued cleanup can't be dropped.
• Bugbot's follow-up is fixed in 3c8e84d: the pipeline issue now closes only when a Release run's Prepare release step succeeds, so a run where preflight skips no longer closes an open alert.

Trade-off: the drop happens on the first failure, and with a green main that's most likely a flake. If nothing new lands afterwards, the 24h staleness check catches it.

[BYK]

I feel like this PR is still unnecessarily complex?

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4f930a2. Configure here.}