feat: add target/N-x-y labels to main branch Chromium roll PRs

[claude]

Requested by John Kleinschmidt · Slack thread

Before: Chromium roll PRs against main always get the no-backport label, so a roll to a Chromium major that a supported release branch is scheduled to ship is never flagged for backporting to that branch. That branch instead gets its own independent Chromium roll PR — so a branch like 45-x-y (scheduled for Chromium 156, currently on the same milestone as main) would end up with both the backported main roll and a duplicate independent roll.

After: Chromium roll PRs against main get a target/N-x-y label for every supported release branch whose scheduled Chromium version is >= the Chromium major being rolled to, and no-backport is only applied when no target branch applies. The main branch is rolled first, and a release branch skips its own Chromium roll only when the main roll PR was successfully created/updated and labeled with target/ for it and the branch's DEPS has kept pace with the Chromium version main has actually landed — so a branch whose backports stall (or when the main roll fails, is paused, or mislabeled) still pulls itself forward with its own roll, and an explicitly targeted roll of a single branch is never suppressed. The backport labels on the long-lived main roll PR are reconciled on every run (including runs with no DEPS change, since the schedule moves independently): stale target/N-x-y labels and a conflicting no-backport are removed before the current set is added, the PR can never carry both no-backport and target/, and on any reconciliation failure the PR's existing backport labels are left untouched. All other labels (merged/*, trop's, semver/*, ...) are never touched, and Node.js rolls are unchanged.

This makes roller label main Chromium roll PRs for backport to the release branches that will ship that Chromium, per the release schedule, instead of rolling those branches separately.

How: a new getBranchesTrackedByMain() util fetches https://releases.electronjs.org/schedule.json (the JSON API behind the schedule page, served by electron/release-status), intersects it with the supported release branches (via getSupportedBranches() on protected branches), and returns every branch whose chromiumVersion milestone is >= the given major. updateLabels() in roll.ts maps that to target/N-x-y labels for Chromium rolls on main, transitions the backport label set only after every conflicting label is confirmed removed (a 404 counts as removed; only a brand-new PR falls back to no-backport on failure), and reports the covered branches back through roll(); handleChromiumCheck() rolls main first and passes that coverage (plus main's landed DEPS version) to rollReleaseBranch(), which skips only branches that are covered and level with what main has landed. If the schedule fetch fails, the roll itself still proceeds.

Example: with Electron 45 (45-x-y) scheduled for Chromium 156 and Electron 44 (44-x-y) for 152, a main roll to Chromium 154 gets target/45-x-y, and 45-x-y skips its own roll while its DEPS is level with what main has landed; a roll to 152 gets both labels; a roll to 157+ gets no-backport and both branches roll independently.

🤖 Generated with Claude Code

[ckerr]

AI-assisted review: Sol xhigh doing adversarial review on the PR, and then Opus 5 high doing an adversarial review on both the PR and on Sol's findings. Inline comments generated by Sol & Opus. All findings reviewed manually by me before submitting.

[ckerr]

Only one significant finding this time. One more pass and we should be g2g

Same review process as before: Sol xhigh adversarial review + Opus 5 high adversarial review of both the PR and of Sol's findings. Reviewed manually by me before submitting.

[ckerr]

Thanks for the updates!

[dsanders11]

Suggested change

	const TARGET_BRANCH_LABEL_PATTERN = /^target\/\d+-(?:\d+-x|x-y)$/;
	const TARGET_BRANCH_LABEL_PATTERN = /^target\/\d+-x-y$/;

This was supporting a very old branch naming pattern (<major>-x) that we never use for target branch labels.

[dsanders11]

We should move away from this pattern , as it is quite slow (as in 20+ seconds, see electron/sudowoodo#419). There was a time historically when protected: true filtered us down to release branches for free as they were the only ones protected, but with our modern branch protection rulesets on e/e all branches count as protected, so this just paginates all branches (which at the time of this writing, is 478).

I'll open a follow up PR for speeding this up, as the changes in this PR add another pagination to the main code paths so we're going to be losing nearly a minute of wall time just paginating branches from e/e.