Repository navigation
fleet-report: CI hours measured from job times; they correct the pre-fix readings - #35
Merged
Merged
Conversation
Occupancy readings before 2026-10-31 left out jobs running inside runs GitHub still lists as queued, and days before the readings only have a 5% run sample. Job times stay readable, so measure them: REST listings (paced, with a floor left for churn) and batched GraphQL check runs (about 1 point per 50 runs). Resumable; summarize gives exact runner minutes per day, peak, minutes at the pool limit, and the old readings against the exact count. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ct the old readings
runner_exact.json on the dashboard branch (written by
scripts/backfill_exact_runner_time.py, read and never written by the action)
holds days measured from every job's own start and end, every repo. Those days
beat occupancy readings and the run sample for this repo's and the whole pool's
hours, draw in the darkest grey ("measured (job times)"), and their
per-minute counts replace the running count of readings taken before
2026-10-31, which left out jobs inside runs GitHub still lists as queued.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GitHub gives a job cancelled before a runner took it a start (its creation) and an end (the cancel). On 2026-10-05, 54 of the 60 jobs counted at the peak minute were such, which put the measured peak at 66 on a 20-runner pool. measure_run (the run sample) skips cancelled jobs with no runner_id. The backfill's new `cancelled` pass reads cancelled jobs' step counts from GraphQL (40 checked against REST: no runner <=> no step) and summarize leaves out those with none. Run node ids are built from the repo and run ids (checked against REST, and against the databaseId each query returns). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Job times on 2026-10-05..13 show up to 65 GitHub-hosted jobs running at once (separate runners, steps starting within a second of pickup) on an account the dashboard treats as a 20-runner pool. Capping a measurement at the pool would hide that, and the alert called anything over it an estimate fault. A measured day keeps its hours; its alert says more runners than runner-pool ran. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
squid-protocol
added a commit
that referenced
this pull request
Oct 31, 2026
Every job of every squid-protocol repo, from scripts/backfill_exact_runner_time.py (squid-bot PR #35): rerun copies and jobs that never held a runner left out; every day peaks at exactly the 20-runner pool. Read by fleet-report once #35 merges; unused before that. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
squid-protocol
added a commit
that referenced
this pull request
Oct 31, 2026
runner time: drop rerun copies and jobs that failed while they waited (follow-up to #35)
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.
Follow-up to #34. Readings before 2026-10-31 left out jobs running inside runs GitHub still lists as
queued(14.75 read while 19.25 ran), and days before the readings only have a 5% run sample (about ±15%, gitgalaxy only). Every job's start and end stay readable, so finished days can be measured instead of estimated.scripts/backfill_exact_runner_time.pyfetch: lists every run of every repo of the owner (REST, held to--rest-per-hour, pausing below--rest-floorremaining so churn keeps its budget) and reads each run's jobs, every attempt, from GraphQL (WorkflowRun.checkSuite.checkRuns, 50 runs a query, about 1 point). Check-run ids and times are the jobs' (checked against REST: identical). Resumable.summarize: per UTC day, the runner minutes of the whole pool and per repo, peak running jobs, minutes at the pool's limit, and per-minute counts for the readings era. Writesrunner_exact.json.fleet_report.py reads
runner_exact.jsonfrom the published branch (never writes it, likeoccupancy_backfill.jsonl):running_in_queued_runs) on a measured day get the measured running count at their minute. What they read is kept asrunning_read. That fixes the runners-in-use panel and the occupancy figures without rewriting the raw readings.Data: a full backfill (2026-09-14 → 2026-10-30, all 20 repos) is running on the host.
runner_exact.jsongoes to thedashboardbranch once it's checked: peak never above 20, old readings against measured counts.Tests: 3 new (
test_job_times_*,tests/test_backfill_exact.py); suite 163 passed, 7 skipped.🤖 Generated with Claude Code