perf(pr-merge): batch main's whole-suite runs and stop sleeping after the dispatch by kyle-sexton · Pull Request #10491 · melodic-software/claude-code-plugins

kyle-sexton · 2026-10-27T16:50:35Z

No related issue: efficiency plan items 5 and 7(b)

Summary

Main runs the whole pr-require-checks suite once per merge: 116 workflow_dispatch runs a day at a median 84.1 runner-min, about 9,740 runner-min a day. The push job that starts each run then sleeps on a held runner (up to 13 reads, 3 minutes apart) only so a red run reaches post-merge-demotion-alert.yml: 105 push runs a day at a median 644 s, about 1,130 runner-min a day. Figures are from the efficiency plan of 2026-10-26.

This PR caps main's whole-suite runs at one per 30 minutes, each of main's tip and so covering every merge since the last. It also ends the push job once it dispatches. The owner decided both (plan items 5 and 7(b)). The cost is attribution: a red run of main now spans up to about 3 merges instead of 1.

Fix

Item 5: the cap, and a run for every merge. A new step, Read main's full-run cover, has the same body in dispatch-full-run and post-merge-dispatch. It reads the newest 20 pr-require-checks.yml dispatches on main that github-actions[bot] started, leaving out cancelled ones. It sets two outputs:

capped=true when one of them was created in the last 30 minutes.
uncovered=true when none of them is at this run's github.sha.

A failed read sets neither output, so the job dispatches as it did before this change.

dispatch-full-run (push, and the merge job's path) dispatches only when not capped.
post-merge-dispatch (the 15-minute schedule) dispatches when not capped and either the post-merge check asks for a run (needsDispatch, as before) or main's tip is uncovered. This is the backstop. The cover step has no if:, so it runs while the kill switch or report-only is on. check-kill-switch always exits 0 (.github/actions/check-kill-switch/action.yml:5), so the steps before it cannot fail the job. Any merge, whoever made it, gets a run of main's tip at most about 30 + 15 minutes after it lands: from the next push after the window, or from the first scheduled run after the window. A merge is never left without a whole run.
The post-merge check counts a run at any descendant of the merge. _judge's relevant() is run.created_at >= merged_at and ctx.contains(commit, run.head_sha), so one run of the tip verifies every merge in the batch. A merge with no run yet reads dispatch-run-pending, and a run still in progress reads dispatch-run-in-progress. Both are pending, which is exit 5 (verdict_exit: unverified with no failure is EXIT_UNVERIFIED), not a failure. The cap plus the backstop stays far inside the check's 6-hour DISPATCH_DEADLINE.

Item 7(b): no sleep after the dispatch.

dispatch-full-run now has three steps: read the cover, dispatch, record. Its timeout drops from 45 to 10 minutes.
The wait step's alert send moves to post-merge-dispatch, in a new step, Send a red full run to the demotion alert. Each scheduled run reads the pr-require-checks dispatches on main from the last 6 hours. It sends the oldest red one that was not sent before, judged on attempt 1, by run id and head SHA, and records it as pr-merge-alerted-<id>. It sends one run per job, so a red streak costs one alert job per tick. It runs whatever the kill switch says, as the old wait step did.
A red main now reaches the alert up to 15 minutes later than before.
No permission moves:
- post-merge-dispatch already holds actions: write.
- dispatch-full-run keeps actions: write only.
- Nothing is added to pr-require-checks.yml (alternative 7(a) was not chosen).
The rate-limit handling is the re-run step's: a limited call stops the step red, and the job's rate-limited output carries the stop. Any other failed read or send leaves the run to the next tick.

pr-require-checks.yml concurrency (Automation Lanes, kept minimal). One predicate and one expression change. A workflow_dispatch on refs/heads/main at run_attempt == 1 joins the group pr-require-checks-main-dispatch, with no queue key and cancel-in-progress false. Every other run keeps its group and cancel-in-progress: true, as before. A re-run keeps its own run_id group, so a newer dispatch can never replace the one re-run a red run waits on. The cancel expression follows release-publish-plugins.yml's precedent (${{ github.event_name != 'push' }}). The github-iac#378 reason for dropping shared groups does not apply here. That reason was a required ci-status left unreported on a PR. A main dispatch reports no required check, and the ci-lanes status readers (fix-ci-dispatch.mjs, the contract-only run) read PR heads only.

The docs this relies on (Control the concurrency of workflows and jobs, source data/reusables/actions/actions-group-concurrency.md in github/docs, read 2026-10-27):

When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending. By default, any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place.

single (default): At most one job or workflow run can be pending in the concurrency group. When a new job or workflow run is queued, any existing pending job or workflow run in the same group is canceled and replaced.
max: Up to 100 jobs or workflow runs can be pending in the concurrency group. When the queue is full, any additional jobs or workflow runs are canceled.

To conditionally cancel currently running jobs or workflows in the same concurrency group, you can specify cancel-in-progress as an expression with any of the allowed expression contexts.

With queue: max, pending runs would pile up and nothing would batch. A workflow test pins that the group sets no queue key.

A replaced run is no signal. GitHub creates the replaced run and then cancels it before any job starts. Runs 40192695442 and 40112740615 (work-resolve-issue.yml, a workflow-level group with cancel false) read conclusion: cancelled, total_count: 0 jobs, and run_started_at == created_at. run_started_at therefore cannot tell such a run from one that started. The jobs count can. Each reader of a cancelled main full run:

babysit_postmerge.py: changed. On main it read a replaced run as RERUN, so the merge was held attribution-pending, the run was marked for a re-run of no jobs, and a replaced run could become the baseline. _Context.replaced() (attempt 1, cancelled, 0 jobs) filters it out of check()'s full runs, the dispatch-listing completeness check, _lane_reruns and _baseline. A run cancelled after its jobs started still reads red.
post-merge-demotion-alert.yml: changed. The File step exits with nothing filed for a cancelled full run whose attempt lists 0 jobs. A failed read files as before.
maintenance-monitor-signals collect.mjs:133: no change. It already skips cancelled.
red-main report.mjs:246 and red-main.mjs:81: no change. They act on failure only.

Known race. A push job and a scheduled run can both read the cover as uncapped and both dispatch. That costs at most one extra run per window, and the group absorbs it: the second run waits, or replaces a waiting one.

API cost. About 2 reads per scheduled run (cover, alert listing) and 1 per push (cover). Before, each merge cost up to 13 polls.

Verification

Tests that fail on main and pass here. Each was checked by swapping in origin/main's three workflow files:

.github/scripts/pr-merge/workflow.test.mjs
- dispatch-full-run ends once it dispatches, with no wait on its run.
- Both jobs' cover steps have the same body, a 30-minute cap, and github.sha as the tip.
- Cap within 30 min. No cap past 30 min, and a run at the tip covers it.
- Cancelled and other actors' runs neither cap nor cover.
- A failed read sets nothing.
- Dispatch conditions: dispatch-full-run starts nothing within the cap. post-merge-dispatch starts an uncovered tip for any merge, outside the cap only.
- post-merge-dispatch reads the cover whatever the kill switch says.
- pr-require-checks: main dispatches share one group, set no queue key and do not cancel. A re-run keeps its own group. The control test (every other run keeps its group and cancel) passes on main and here.
.github/scripts/pr-merge/merge-job.test.mjs: these port the wait step's alert-send tests to the new step.
- A red run is sent once, by id and SHA, and recorded.
- Every FAILED_CONCLUSION is sent.
- Green, running, other-actor, already-sent and replaced runs are not.
- Attempt 1 decides.
- The oldest red run goes first.
- A failed read skips that run.
- The three-try jittered resend.
- A rate limit stops red.
- The step's if: and position.
plugins/source-control/skills/babysit-prs/scripts/tests/test_babysit_postmerge.py ReplacedRuns: a replaced run neither holds nor re-runs the merge, and is no baseline. The control (cancelled after jobs started still waits for its re-run) passes on both.
scripts/post-merge-demotion-alert.test.sh: a dispatched run cancelled before any job started files nothing, and one cancelled once its jobs started files a record.

Runs:

node --test on both pr-merge test files: 148 pass.
scripts/post-merge-demotion-alert.test.sh: PASS=156.
babysit-prs pytest: 3191 passed. One earlier -x run stopped on 1 failure that the full run did not repeat. Its name was lost, so it is UNVERIFIED as a flake.
actionlint on the three workflows: clean.
scripts/ci-review-lanes.test.sh: PASS=98.
scripts/run-ruff.sh check and format: clean.
scripts/check-affected.sh: 14 passed, after merging origin/main.

Expected re-measure (from the plan):

workflow_dispatch runs of pr-require-checks on main per day: 116 → at most 48.
Whole-suite runner-min per day: 9,740 → at most 4,100, saving at least 5,700.
The in_progress p90 falls from 41 (limits/concurrency.jsonl).
pr-merge push success median: 644 s → under 60 s, saving about 1,130 runner-min a day.
Time from a red main to the alert: at most 15 minutes after the run ends (events.log).
About 25-35 fewer GITHUB_TOKEN calls an hour.

Throughput risk the plan did not weigh. merge.max-in-flight is 5 (docs/conventions/pr-pipeline.yaml). It counts queued lane entries plus merged lane PRs not yet verified (babysit_merge_policy.in_flight). A merge now waits up to 30 minutes for its batch run, plus the run, plus a tick. Main's whole runs take about 8 minutes of wall time: p50 8 and p90 9 over the last 53 attempt-1 dispatch runs, read 2026-10-27. So verification of a merge moves from about 8-23 minutes to as much as about 68 minutes (30 cap, 15 to the next tick, 8 run, 15 to the tick that reads it). At about 5.5 lane merges an hour, the lane can reach the in-flight cap and hold new enqueues for part of each window. Re-measure the gate's unverified-auto-merge refusals after merge. The owner's options are to keep 30 minutes, raise max-in-flight, or shorten the cap.

Efficiency plan 2026-10-26, items 5 and 7 (owner decision: alternatives 5-recommended and 7(b)).
pr-require-checks.yml's concurrency block belongs to the Automation Lanes session. The change there is one predicate and the cancel expression.
Open branches touching pr-merge.yml: #10475 (post-merge-dispatch), perf/verify-incremental-listing, fix/holdpath-clears-on-security-pass. This PR's edits stay within dispatch-full-run, post-merge-dispatch's dispatch steps, and the job headers.

🤖 Generated with Claude Code

… the dispatch dispatch-full-run and post-merge-dispatch read main's newest pr-require-checks dispatches first and start none within 30 minutes of the last; post-merge-dispatch starts main's tip on its next scheduled run when no run covers it, for any merge and whatever the kill switch says. dispatch-full-run ends after it dispatches; post-merge-dispatch sends a red full run to post-merge-demotion-alert.yml once per run. pr-require-checks.yml gives attempt 1 of a main dispatch one concurrency group with no queue key and cancel-in-progress false; a re-run keeps its own group. The post-merge check and the alert skip a run that group replaced before it started (cancelled, no job). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

chatgpt-codex-connector · 2026-10-27T18:13:42Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-27T18:16:22.858049Z	`c482234`	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c482234897

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

github-actions · 2026-10-27T18:16:53Z

claude-review reviewed 9a85df6afd695065f8c4e28871a4d765a1786d96: 0 finding(s), 0 as inline comments.

Code review: PR #10491 (batch main's whole-suite runs, drop the post-dispatch sleep)

Result: 0 findings. This was a static read of .claude-lane/pr.diff and .claude-lane/pr-context.md. I had no shell, so I ran no tests. Every test result quoted in the PR body is author-claimed and unverified by me.

What I checked

Cover step. The two copies differ only in how they classify a rate-limited read, and the diff matches the tests that pin that. Failed-read, rate-limit, cancelled-run and other-actor handling are consistent with the stated behavior.
dispatch-full-run. It now reads the cover, dispatches and records, and nothing else. The wait step's rate-limit handling and send retries moved intact into the new alert step in post-merge-dispatch.
Alert step.
- A send is skipped only when --lane-alerted exits 0.
- Exit 4 is the only code that sends. A crash (1), a failed read (3) and any other code leave the run to the next tick.
- A rate limit (75) stops the step red.
- _lane_sender accepts the record only from this repository's own pr-merge.yml on the branch. It checks that the run's head commit is an ancestor of main's tip, so a later tip does not make the record unreadable.
pr-require-checks.yml concurrency.
- Only attempt 1 of a workflow_dispatch on main joins the shared group. Re-runs keep their own run_id group.
- cancel-in-progress is false for that group and true for every other run, as the tests expect. There is no queue key.
babysit_postmerge.py. replaced() (attempt 1, completed, cancelled, 0 jobs) is applied in check()'s full-run list, the dispatch-listing completeness check, _lane_reruns and _baseline. Results are cached per run. _lane_proof is a behavior-preserving extraction from lane_dispatched.
post-merge-demotion-alert.yml. The new zero-job check applies only to a cancelled non-canary run. A failed jobs read falls through and files, as the PR says.

Notes, not counted as findings

The PR body says the cover step in post-merge-dispatch "has no if:". The diff gives it if: steps.kill.outputs.proceed == 'true' && steps.mode.outputs.live == 'true', and the tests and the changelog agree with the diff. The body is stale on this point.
Throughput. The PR body flags that verification of a merge can slow from about 8–23 minutes to as much as about 68. At that delay the lane's max-in-flight of 5 may hold new enqueues for part of each window. That is an owner decision the author already surfaced, so I did not raise it as a defect. Re-measure unverified-auto-merge refusals after merge.
Alert step ordering. One alert is sent per scheduled run, oldest first. A send that fails for a non-network reason (the step breaks out of the retry loop and exits 0 with a warning) is retried first on every tick. It can delay newer red runs until it ages out of the 6-hour lookback. I think this is an acceptable edge case, and a failed send is not a plausible steady state.
Spend. This change only reduces Actions minutes and API calls. It adds about 2 reads per scheduled run and 1 per push. It touches no paid plan or billing setting, so there is no cost hold.
Manifests. The diff changes no plugin.json or marketplace.json, so no manifest lines apply. The two changelog fragments both use bump: patch.
Closing issues. The PR names none ("No related issue"), so there are no acceptance criteria to check.

github-actions

claude-security-review: 1 inline finding(s) on c482234897d151ed56dcb557bc71e4130799d544; the summary is in this lane's pull request comment.

claude-lane: claude-security-review

github-actions · 2026-10-27T18:17:06Z

claude-security-review reviewed 9a85df6afd695065f8c4e28871a4d765a1786d96: 0 finding(s), 0 as inline comments.

No security findings. I read the whole diff and the PR context. The files that carry a trust control are .github/workflows/pr-merge.yml, .github/workflows/pr-require-checks.yml and babysit_postmerge.py. Nothing here widens who is trusted, what a token can do, or the reach of the kill switch.

critical-findings: 0

manifest: no plugin manifest is touched.

What I checked

Token scope. post-merge-dispatch already held actions: write, and the diff only extends the comment on that line. dispatch-full-run drops to actions: write alone. No permission is added.
Kill switch.
- post-merge-dispatch: the cover, dispatch and alert steps all require steps.kill.outputs.proceed == 'true' and steps.mode.outputs.live == 'true'.
- Alert step: the old wait step sent a red run to the alert even with the switch on. The new step sends nothing in that state. That is stricter, so it does not widen the switch's reach.
- dispatch-full-run: it keeps its existing carve-out of dispatching on push even with the switch on. The cap only reduces how often it dispatches.
Alert sender.
- The step sends only runs whose actor.login == "github-actions[bot]" and head_branch == "main".
- It checks that id and sha match ^[1-9][0-9]{0,14}$ and ^[0-9a-f]{40}$ before they reach gh api -f, so there is no injection.
- post-merge-demotion-alert.yml still re-validates run id, head SHA, actor and conclusion on its own side, and the diff does not loosen that.
- The pr-merge-alerted-<id> record counts only when _lane_sender accepts the uploading run, which requires one of schedule or workflow_dispatch. A same-name artifact from another run does not suppress an alert, and a crash or failed read never exits 4, so it never triggers a send.
Main-dispatch concurrency group.
- Only a workflow_dispatch on refs/heads/main at attempt 1 joins the shared group. Every other event keeps its own group and cancel-in-progress: true.
- Someone who can dispatch on main already holds write access and can already dispatch runs.
- Replacing a waiting run is an availability effect, not a bypass. The backstop (uncovered) starts a run of the tip on the next scheduled run.
replaced() filter in babysit_postmerge.py.
- It excludes only attempt 1, completed, cancelled runs with total_count == 0.
- A run that failed or was cancelled after its jobs started still reads red.
- A replaced run being ignored leaves its merge unverified, so the merge reads as pending (exit 5, no run yet). It never reads as passing.
- The listing read fails closed: a non-integer total_count raises PostMergeReadError.
Cap and cover.
- A failed read sets no output, so the job dispatches as before the change.
- A rate limit stops the step red and the job's rate-limited output carries the stop.
- The uncovered backstop means a merge is never left without a whole run of the tip.
- The batching does not weaken the post-merge verdict, because a run at a descendant of a merge contains that merge, as the existing relevant() rule already requires.

Spend: this only changes spend on GitHub Actions runner minutes. The PR estimates a drop from about 9,740 to at most 4,100 runner-min a day, and no billing setting changes. It is not a hold.

Non-security note: the PR itself flags a throughput risk with merge.max-in-flight. That is for the owner, not a security issue.

…ed job on the kill switch A cover read refused for a rate limit now stops the step red with rate-limited=true. post-merge-dispatch classifies it through rate-stop.bash's rate_stop_from, as its alert step does, and adds the stop to the job's rate-limited output, which the merge and enable-auto-merge jobs already stop on; its dispatch, re-run and alert steps skip after it. dispatch-full-run has no checkout of the guard, so it matches the pattern rate_stop_from reads, as its removed wait step did, and its dispatch skips. post-merge-dispatch reads the cover and dispatches only while the lane is live (kill switch off, report-only off), as its post-merge check does, and sends a red run to the alert only with the kill switch off. dispatch-full-run's push carve-out stays. The tests that pinned the cover and alert as running whatever the switches say now pin the reviewed behavior instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…-batching

The kill switch and report-only now stop everything post-merge-dispatch does that spends API or starts a run: the cover read, the pr-require-checks.yml dispatch on main and the alert dispatch. The alert step had only the kill-switch condition; it now also needs the lane live. dispatch-full-run's push carve-out stays. A test runs the kill-switch action with CLAUDE_LANES_DISABLED and with CLAUDE_LANES_REPO_DISABLED set, then evaluates every later step of the scheduled job over its output: none that starts a full run or sends an alert runs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…-batching

github-actions

claude-security-review: 1 inline finding(s) on 8c01e4f8388889dccd59fe14287b49ce96e6a22d; the summary is in this lane's pull request comment.

claude-lane: claude-security-review

… on main The alert step treated any artifact named pr-merge-alerted-<id> as a send already made, whoever uploaded it, so a pull request run could suppress a red run's alert. It now asks babysit_postmerge.py --lane-alerted, which accepts the record only from a sender the dispatch and re-run records' rule accepts (_lane_sender: this repository's pr-merge.yml, a schedule or workflow_dispatch run, on main, head commit on main's tip). _lane_record and the new lane_alerted share one _lane_proof helper. Exit 75 stops the step red as a rate limit; any other failed read sends nothing for that run, as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…-batching

github-actions

claude-review: 1 inline finding(s) on e76e2c46dc0021fd9fc01d5490be8e01f2e0deee; the summary is in this lane's pull request comment.

claude-lane: claude-review

--lane-alerted answered "not recorded" with exit 1, which is also what Python exits with on any uncaught exception, so a crashing check fell through to the send and sent the same red run again every tick. It now answers EXIT_NOT_ALERTED (4), a code no crash (1), argparse refusal (2), failed read (3) or rate limit (75) produces. The alert step sends only on 4; 1 and every other unknown code warn and leave the run to the next run, as a failed read does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…-batching

melodic-automation-lanes · 2026-10-27T22:49:42Z

The pr-unblock lane stopped on this pull request and needs a person: the lane could not resolve every conflict.

Reason: unresolved-conflict
Resume key: e76e2c46dc0021fd9fc01d5490be8e01f2e0deee (the head the lane stopped on)

To resume, deal with the reason above, remove the needs-human label (and do-not-merge, if set), then dispatch the pr-unblock workflow with pr-number=10491 and activity=resolve-conflicts:

gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=10491 -f activity=resolve-conflicts

…-batching # Conflicts: # .github/scripts/pr-merge/workflow.test.mjs

melodic-automation-lanes · 2026-10-27T23:41:47Z

The pr-unblock lane escalated this pull request as unresolved-conflict, and that no longer holds at 9a85df6afd695065f8c4e28871a4d765a1786d96: GitHub reports no conflict with main. pr-merge removed needs-human, so the lanes run on it again. To keep a person on it, add needs-human back: a label a person adds is never removed.

github-actions · 2026-10-28T00:48:27Z

Post-merge mutation testing

Range: 01c32cb..1913f45
Merged pull request: #10491
Outcome: reported

Killed 0, survived 0, timeout 0, no coverage 0, invalid 0, not run 8.
Covered-code score n/a; mutation score n/a.

File	Killed	Survived	Timeout	No coverage	Invalid	Not run
`plugins/source-control/skills/babysit-prs/scripts/babysit_postmerge.py`	0	0	0	0	0	8

The run's summary has the full report.

kyle-sexton force-pushed the perf/main-whole-suite-batching branch from 847d3dd to c482234 Compare October 27, 2026 18:08

kyle-sexton marked this pull request as ready for review October 27, 2026 18:13

chatgpt-codex-connector Bot reviewed Oct 27, 2026

View reviewed changes

Comment thread .github/workflows/pr-merge.yml Resolved

github-actions Bot reviewed Oct 27, 2026

View reviewed changes

Comment thread .github/workflows/pr-merge.yml Resolved

kyle-sexton and others added 4 commits October 27, 2026 15:35

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

0d550db

…-batching

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

8c01e4f

…-batching

github-actions Bot reviewed Oct 27, 2026

View reviewed changes

Comment thread .github/workflows/pr-merge.yml Resolved

kyle-sexton and others added 2 commits October 27, 2026 16:23

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

e76e2c4

…-batching

github-actions Bot reviewed Oct 27, 2026

View reviewed changes

Comment thread .github/workflows/pr-merge.yml Resolved

kyle-sexton and others added 5 commits October 27, 2026 17:24

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

b93a672

…-batching

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

dc92434

…-batching

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

618248b

…-batching

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

ec00af0

…-batching

melodic-automation-lanes Bot added the needs-human Human-in-the-loop required; autonomous sessions must not resolve items carrying this. label Oct 27, 2026

Merge remote-tracking branch 'origin/main' into perf/main-whole-suite…

9a85df6

…-batching # Conflicts: # .github/scripts/pr-merge/workflow.test.mjs

melodic-automation-lanes Bot removed the needs-human Human-in-the-loop required; autonomous sessions must not resolve items carrying this. label Oct 27, 2026

kyle-sexton added this pull request to the merge queue Oct 28, 2026

Merged via the queue into main with commit 1913f45 Oct 28, 2026
101 of 104 checks passed

kyle-sexton deleted the perf/main-whole-suite-batching branch October 28, 2026 00:36

Navigation Menu

Repository navigation

perf(pr-merge): batch main's whole-suite runs and stop sleeping after the dispatch - #10491

perf(pr-merge): batch main's whole-suite runs and stop sleeping after the dispatch#10491
kyle-sexton merged 13 commits into
mainfrom
perf/main-whole-suite-batching

kyle-sexton commented Oct 27, 2026

Uh oh!

chatgpt-codex-connector Bot commented Oct 27, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

github-actions Bot commented Oct 27, 2026 •

edited

Loading

Uh oh!

github-actions Bot left a comment

Uh oh!

Uh oh!

github-actions Bot commented Oct 27, 2026 •

edited

Loading

Uh oh!

github-actions Bot left a comment

Uh oh!

Uh oh!

github-actions Bot left a comment

Uh oh!

Uh oh!

melodic-automation-lanes Bot commented Oct 27, 2026

Uh oh!

melodic-automation-lanes Bot commented Oct 27, 2026

Uh oh!

Uh oh!

github-actions Bot commented Oct 28, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

kyle-sexton commented Oct 27, 2026

Summary

Fix

Verification

Related

Uh oh!

chatgpt-codex-connector Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codex Review Summary

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

github-actions Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code review: PR #10491 (batch main's whole-suite runs, drop the post-dispatch sleep)

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

melodic-automation-lanes Bot commented Oct 27, 2026

Uh oh!

melodic-automation-lanes Bot commented Oct 27, 2026

Uh oh!

Uh oh!

github-actions Bot commented Oct 28, 2026

Post-merge mutation testing

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

chatgpt-codex-connector Bot commented Oct 27, 2026 •

edited

Loading

github-actions Bot commented Oct 27, 2026 •

edited

Loading

github-actions Bot commented Oct 27, 2026 •

edited

Loading