fix(infra): exempt release PRs from stale cleanup - #5145
Merged
Mason Daugherty (mdrxy) merged 5 commits intoJul 29, 2026
Merged
Conversation
github-actions
Bot
added
fix
![open-swe[bot]](https://avatars.githubusercontent.com/in/1395372?s=60&v=4){kind=small}
Review found the exemption inverted relative to its own reasoning. It required a release label AND release-please provenance, while the comments correctly noted the labels are the unreliable signal: `release` is applied by a continue-on-error step in release-please.yml, and RELEASING.md documents hand-editing `autorelease: pending`. A genuine release PR holding neither label passed every provenance check, was denied the exemption, and would be warned and then closed 16 days later on a green run — with no log line at all, since the drift warning only fired for the inverse (and harmless) case. Provenance now decides alone. Every conjunct is unspoofable by a contributor: an outside PR cannot push a branch into this repository nor author as github-actions[bot]/Bot, so the label requirement bought no security and was the only thing able to produce that false negative. This matches existing repo practice — check_sdk_pin.yml, check_partner_bounds.yml and release-notes.js all identify release PRs by branch name alone. RELEASE_LABELS is kept purely as a diagnostic: a label without provenance still warns (spoof or genuine drift), and provenance without a label now warns too, since per RELEASING.md a missing `autorelease: pending` blocks release-please from opening future release PRs. A test had locked the old behavior in, asserting that a full-provenance PR with no release label gets warned. Its actual purpose — guarding Set.has() against substring matching — is now served by a contributor fixture, which is where that distinction bites. Alongside: - Bind RELEASE_PLEASE_BRANCH_PREFIX to release-please-config.json in a test. The literal is duplicated across five workflows and nothing noticed when the config that determines the real branch name changed; here the consequence is closing real release PRs. - Log and count the sweep's 404 skip. It was the one remaining path where the sweep could drop every PR and still look like a sweep with nothing to do — the exact shape the previous commit set out to fix one branch above. - Sort the sweep query oldest-first. Its cap comment claimed the next run picks up what was missed, but without a deterministic order GitHub search can return the same over-cap subset forever, starving a PR rather than deferring it. - Throw on an unrecognized processPr result instead of creating a NaN counter, now that two dialects of result string exist. - Suppress the sweep's anomaly warning; processPr already reported it for the same PR in the same run, and a PR in both searches warned twice. - Report provenance failures as `<absent>` rather than `undefined` so a null head.repo is diagnosable as absent rather than mismatched. - core.error, not core.warning, for the now-fatal sweep failure. - Fix the RELEASING.md label table, which described only the post-merge meaning of `autorelease: pending` and so contradicted the code comment that depends on it being present pre-merge. - Document that release PRs open as drafts, so the exemption only covers the ready-for-review window and skippedRelease normally reads 0. That was the missing precondition most likely to get the guard deleted as dead code.
Mason Daugherty (mdrxy)
deleted the
mdrxy/infra/exempt-release-prs-from-close-old-prs
branch
July 29, 2026 19:04
Marcelo5444
pushed a commit
to Marcelo5444/deepagents
that referenced
this pull request
Jul 30, 2026
Release-please's PRs are no longer warned or auto-closed by the old-PR cleanup, and any existing `pending-deletion` label is removed from them on the next run. --- Release-please keeps one long-lived PR per package and updates it in place, so "days since opened" — the only staleness signal this workflow has — is meaningless for them. langchain-ai#4297 was warned by this workflow on 2026-07-29 at 33 days old and needed a manual `do-not-close` to survive. Requiring that label duplicates what release-please already maintains. A PR is exempt when it carries `release` or `autorelease: pending` **and** was opened by `github-actions[bot]` on a `release-please--branches--main--components--*` branch in this repository. The label alone is not enough: `release` is derived from the PR title by the unified labeler, and `release` is an allowed title type, so a label-only check would let any contributor opt their own PR out of cleanup indefinitely. When a release label appears without matching provenance, the run logs a warning — so genuine drift (a renamed default branch, a `separate-pull-requests` flip, a token change) surfaces in the log instead of silently closing release PRs again. The stale-label sweep uses the same classification, so already-warned release PRs recover automatically. Draft and `do-not-close` behavior and the age thresholds are unchanged. The run summary gains a `skippedRelease` sub-count so an over-applying exemption is visible at a glance. Two pre-existing sweep bugs are fixed alongside, since this change routes a new category of PR through it: - The sweep swallowed non-404 errors into a warning and returned a green run, so a sweep that died on its first PR looked identical to one with nothing to do. It now fails the run, matching how a failed PR search is already handled. **This can turn a currently-green run red if the sweep has been quietly failing.** - `staleCleared` counted PRs whose label was already gone — the label search index lags the removals made earlier in the same run. Only real removals are counted now, so the number may read lower than before.
Mason Daugherty (mdrxy)
added a commit
that referenced
this pull request
Jul 30, 2026
Release-please's PRs are no longer warned or auto-closed by the old-PR cleanup, and any existing `pending-deletion` label is removed from them on the next run. --- Release-please keeps one long-lived PR per package and updates it in place, so "days since opened" — the only staleness signal this workflow has — is meaningless for them. #4297 was warned by this workflow on 2026-07-29 at 33 days old and needed a manual `do-not-close` to survive. Requiring that label duplicates what release-please already maintains. A PR is exempt when it carries `release` or `autorelease: pending` **and** was opened by `github-actions[bot]` on a `release-please--branches--main--components--*` branch in this repository. The label alone is not enough: `release` is derived from the PR title by the unified labeler, and `release` is an allowed title type, so a label-only check would let any contributor opt their own PR out of cleanup indefinitely. When a release label appears without matching provenance, the run logs a warning — so genuine drift (a renamed default branch, a `separate-pull-requests` flip, a token change) surfaces in the log instead of silently closing release PRs again. The stale-label sweep uses the same classification, so already-warned release PRs recover automatically. Draft and `do-not-close` behavior and the age thresholds are unchanged. The run summary gains a `skippedRelease` sub-count so an over-applying exemption is visible at a glance. Two pre-existing sweep bugs are fixed alongside, since this change routes a new category of PR through it: - The sweep swallowed non-404 errors into a warning and returned a green run, so a sweep that died on its first PR looked identical to one with nothing to do. It now fails the run, matching how a failed PR search is already handled. **This can turn a currently-green run red if the sweep has been quietly failing.** - `staleCleared` counted PRs whose label was already gone — the label search index lags the removals made earlier in the same run. Only real removals are counted now, so the number may read lower than before.
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
1 participant
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.
Release-please's PRs are no longer warned or auto-closed by the old-PR cleanup, and any existing
pending-deletionlabel is removed from them on the next run.Release-please keeps one long-lived PR per package and updates it in place, so "days since opened" — the only staleness signal this workflow has — is meaningless for them. #4297 was warned by this workflow on 2026-07-29 at 33 days old and needed a manual
do-not-closeto survive. Requiring that label duplicates what release-please already maintains.A PR is exempt when it carries
releaseorautorelease: pendingand was opened bygithub-actions[bot]on arelease-please--branches--main--components--*branch in this repository. The label alone is not enough:releaseis derived from the PR title by the unified labeler, andreleaseis an allowed title type, so a label-only check would let any contributor opt their own PR out of cleanup indefinitely. When a release label appears without matching provenance, the run logs a warning — so genuine drift (a renamed default branch, aseparate-pull-requestsflip, a token change) surfaces in the log instead of silently closing release PRs again.The stale-label sweep uses the same classification, so already-warned release PRs recover automatically. Draft and
do-not-closebehavior and the age thresholds are unchanged. The run summary gains askippedReleasesub-count so an over-applying exemption is visible at a glance.Two pre-existing sweep bugs are fixed alongside, since this change routes a new category of PR through it:
staleClearedcounted PRs whose label was already gone — the label search index lags the removals made earlier in the same run. Only real removals are counted now, so the number may read lower than before.