Repository navigation
Conversation
The bot sweep is the only thing that fills CI on bot PRs and merges them, and it ran only from its hourly cron. GitHub started that cron 3.7 to 9.8 h apart on this repository (22 scheduled runs from 2026-11-01 to 11-07, none hourly), and the CI and canary runs the sweep dispatches with GITHUB_TOKEN start no workflow_run, so nothing followed them: with one bot CI in flight at a time, each bot PR waited a cron gap per step. ci.yml (dispatched on autobump/* or main) and canary.yml (dispatched on autobump/*) now end with job sweep. After every other job, never failing the run, it dispatches bot-sweep.yml on main with after_run set to its own run id, unless fewer than 500 of the hour's 1,000 GITHUB_TOKEN requests remain. The sweep's ci-fill job first waits, 5 min at most, for that run to complete, so the evidence it reads is final. The cron stays as the backstop. tests/ci_wiring_test.sh checks the wiring (needs lists every other job, the if:, actions: write only, the after_run input and the wait before any dispatch) and runs both steps against a fake gh.
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
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.
The bot sweep (bot-sweep.yml) is the only workflow that fills CI on bot PRs and merges them, and it ran only from its hourly cron. That cron is not hourly in practice: GitHub started bot-sweep.yml's 22 scheduled runs from 2026-11-01 14:16Z to 2026-11-07 10:04Z between 3.7 and 9.8 h apart (
gh run list --workflow bot-sweep.yml --event schedule), and the watchdog's own47 * * * *cron has the same gaps. GitHub's documentation says scheduled events can be delayed and dropped under load. The latest gap ran from 02:47Z to 10:04Z today; bot PRs with green CI sat unmerged until someone dispatched the sweep by hand, and the watchdog openedstale:bot-sweep.ymlat 09:55Z.The CI and canary runs the sweep dispatches with GITHUB_TOKEN cannot chain to it through
workflow_run: a run dispatched with GITHUB_TOKEN starts no workflow_run. On 2026-11-01 the ci.yml runs dispatched on main by github-actions[bot] at 19:13Z and 23:07Z, and the release runs it dispatched at 19:38-19:42Z, started no watchdog run, while the push- and schedule-started completions around them (Auto-release AUR, Docs, the 19:38Z and 23:34Z sweeps) each started one within 3 s. So with one bot CI in flight at a time (hack/bot-ci-dispatch), each bot PR step waited a whole cron gap.The change:
autobump/*ormain) and canary.yml (when dispatched onautobump/*) end with jobsweep. It needs every other job, runs unless the run was cancelled, hasactions: writeonly and iscontinue-on-error, so it never changes the run's result. It dispatchesbot-sweep.ymlon main withafter_runset to its own run id, retrying a failed dispatch twice. It readsGET /rate_limitfirst (free) and skips the hand-off when fewer than 500 of the repository's 1,000 hourly GITHUB_TOKEN requests remain: a sweep reads about 10 per open bot PR, and the watchdog and Freshness share that budget.after_run. Its ci-fill job first polls that run (every 5 s, 5 min at most) until it completes, sohack/bot-ci-dispatchandhack/bot-mergeread a finished run. With noafter_run(the cron, a manual dispatch) it waits for nothing; a value that is not digits fails the step. ci-fill's timeout goes from 10 to 15 min to cover the wait.Push-started CI on main does not hand off; only dispatched runs do (bot-merge's post-merge CI on main, the watchdog's, and a bot PR's).
Tests, written first and failing before the change (6 failed, then 5 more for the budget check):
tests/ci_wiring_test.sh: jobsweepin both workflows needs every other job, has theif:, permissions,continue-on-errorand one identical step; bot-sweep.yml has theafter_runinput and the wait step before anyhack/bot-ci-dispatch. Both steps run against a fake gh: the dispatch arguments, a retried 502, three failed dispatches (warning, exit 0), 499 left (no dispatch), 500 left (dispatch), an unreadable budget (dispatch); the wait with no run, a bad id, a run that completes after a failed read, and one still open after 60 reads (warning, sweep goes on). 198 passed.tests/canary_spec_test.sh: the write-permission allowance namessweep, withactions: writeonly. 110 passed.tests/watchdog_test.sh32 passed;python3 tests/ledger_drift_check.pyandtests/claims_check.shpass.Existing bot branches keep their old ci.yml until Freshness regenerates them from main (
hack/autobump-branch-reset), so the hand-off starts on bot runs from then on; a ci.yml dispatch on main exercises it right after the merge.One side effect to know: a scheduled sweep that is pending behind a running sweep is cancelled when a hand-off queues a newer one (concurrency group
bot-sweep), sostale:bot-sweep.yml, which counts scheduled successes only, can open even though sweeps ran.