feat: add target/N-x-y labels to main branch Chromium roll PRs by claude[bot] · Pull Request #207 · electron/roller

claude · 2026-09-01T15:32:50Z

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

When rolling Chromium on main, label the roll PR with target/N-x-y for every supported release branch whose scheduled Chromium version (per https://releases.electronjs.org/schedule.json) is >= the Chromium major being rolled to, so the roll is backported to the branches that will ship it. no-backport is now only applied when no target branch applies. If the release schedule cannot be fetched, the roll still proceeds and falls back to the previous no-backport behavior.

Skip the independent Chromium roll for a release branch whose scheduled Chromium version is >= the major the main branch roll targets (the latest Canary) - such branches receive the main roll via their target/N-x-y label instead, so rolling them separately would produce a duplicate roll PR. The check uses the same schedule predicate as the target label computation; if it cannot be determined, the branch rolls independently as before. Since the main roll PR is updated daily and labels were add-only, also remove roller-managed labels that no longer apply on each update: stale target/N-x-y labels that no longer qualify, and no-backport when target labels currently apply. Other labels are never touched, and removal failures are non-fatal.

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.

- Roll main first and pass the release branches its roll PR actually covers (successfully created/updated and labeled) down to the release branch rolls, instead of re-deriving schedule eligibility per branch. A covered branch is skipped only while its DEPS Chromium version has caught up to the main roll target, so a branch whose backports stall pulls itself forward with its own roll. Explicitly targeted rolls are never suppressed. - Treat the backport label set as a state machine: replacement labels are only added once every conflicting label is confirmed removed (404s count as removed), and on any failure the PR's existing backport labels are left exactly as they were - only a brand-new PR falls back to no-backport. The PR can never carry both no-backport and target/ labels. - Reconcile labels on the open main roll PR even when the DEPS version is unchanged, since the release schedule (e.g. a newly cut branch) moves independently of Chromium. - Widen the stale label pattern to the older N-M-x branch form and guard the Chromium major parse against invalid versions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011v4QNjFUH5wLUj8eMUigbB

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.

The skip condition compared the branch's DEPS Chromium version against the version the open main roll PR targets, which a backport-fed branch can never reach - it is at most level with main's landed version - so the skip was unreachable in steady state and every tracked branch still rolled independently alongside its backport. Compare against main's landed DEPS version instead: level with main means take the backport, behind main means roll independently and self-heal. MainRollResult now carries currentVersion (the version main is on) rather than the roll target, and the handler tests cover the kept-pace skip, the everyday case of a branch level with main while the roll PR is ahead of both, and a lagging branch rolling itself forward. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011v4QNjFUH5wLUj8eMUigbB

ckerr

Thanks for the updates!

dsanders11 · 2026-09-02T17:25:27Z

  previousVersion?: string;
 }

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


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 · 2026-09-03T02:38:59Z

+  const branches: ReposListBranchesResponseItem[] = await octokit.paginate(
+    octokit.repos.listBranches.endpoint.merge({
+      ...REPOS.electron,
+      protected: true,
+    }),
+  );


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.

claude added 2 commits September 1, 2026 15:32

jkleinsc approved these changes Sep 2, 2026

View reviewed changes

jkleinsc marked this pull request as ready for review September 2, 2026 13:53

jkleinsc requested review from a team as code owners September 2, 2026 13:53

ckerr requested changes Sep 2, 2026

View reviewed changes

Comment thread src/utils/roll.ts

Comment thread src/chromium-handler.ts Outdated

Comment thread src/utils/roll.ts

Comment thread src/chromium-handler.ts Outdated

Comment thread src/utils/roll.ts Outdated

Comment thread src/utils/roll.ts Outdated

claude Bot requested a review from ckerr September 2, 2026 14:40

ckerr requested changes Sep 2, 2026

View reviewed changes

Comment thread src/chromium-handler.ts

claude Bot requested a review from ckerr September 2, 2026 17:07

ckerr approved these changes Sep 2, 2026

View reviewed changes

MarshallOfSound merged commit 240f5d9 into main Sep 2, 2026
5 checks passed

MarshallOfSound deleted the feat/main-roll-target-labels branch September 2, 2026 18:29

dsanders11 reviewed Sep 3, 2026

View reviewed changes

Navigation Menu

Uh oh!

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

feat: add target/N-x-y labels to main branch Chromium roll PRs#207
MarshallOfSound merged 4 commits into
mainfrom
feat/main-roll-target-labels

claude Bot commented Sep 1, 2026 •

edited

Loading

Uh oh!

ckerr left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ckerr left a comment •

edited

Loading

Uh oh!

Uh oh!

ckerr left a comment

Uh oh!

Uh oh!

dsanders11 Sep 2, 2026

Uh oh!

dsanders11 Sep 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

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

Uh oh!

Conversation

claude Bot commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ckerr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ckerr left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ckerr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dsanders11 Sep 2, 2026

Choose a reason for hiding this comment

Uh oh!

dsanders11 Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

claude Bot commented Sep 1, 2026 •

edited

Loading

ckerr left a comment •

edited

Loading