Part of #266. Measured over the last 50 CI and Deploy runs (280 hosted jobs). Median time from queued to first step was 15.5 s (p90 44.8 s). This cuts the two largest parts we control:
- A run's jobs start together (services/actions
start_queued_except). Jobs were claimed and their sandboxes started one after another, about 2.4 s per start, so a batch's sixth job waited a median 15.7 s before its sandbox was even asked for. Claiming is still sequential, so the workspace share, max-parallel and concurrency groups still apply; the starts are then made together. A refusal for lack of a machine no longer stops the sweep, because the jobs after it may run on another machine class. - Set up job fetches the job's actions in parallel (crates/runner
uses.rs). Each action took about 1.7 s, one after another: 3.3 s of the 9.7 s from assigned to first step. Each action's lookup and archive download now runs on its own thread; the log is unchanged and in order, and a lookup or download that didn't arrive is retried as before.
Expected: median queued to first step from about 15.5 s to about 9 s. Nothing is kept warm, so cost is unchanged. The full breakdown is on #266.
Tests: cargo test -p g1t-actions-service and cargo test -p g1t-runner actions:: pass. A new test checks that three actions' lookups and downloads overlap.