Day 8 of the ubuntu-latest rollout: Monday — run Sunday's checklist against the first weekday runs

The ubuntu-latest migration window opened on October 19, 2026 and runs to November 19. Inside that window, ubuntu-latest moves from Ubuntu 24.04 to Ubuntu 26.04 in stages, so any single run may land on either image. Day 7 turned the weekend log into a short Monday checklist. Day 8 is Monday, the start of the second rollout week: the checklist now meets its first real runs, and the comparison either clears a suspicion or keeps it open — it rarely settles one outright.

What Monday's first runs can show

A suspicious weekend failure that repeats with the same first error line on a fresh weekday run was probably never the image — the same failure on two separate days points at the workflow, not the rollout. A suspicious failure that does not repeat proves less: the new run may have landed on the other image, so the entry stays on the list rather than coming off it. Monday's value is in narrowing, not closing: each comparison removes the failures that were never drift, and leaves a shorter, more honest list of what is still unexplained.

The 10-minute Monday pass

  1. Take Sunday's checklist in order. For each "suspicious" entry, find the first matching run today and compare the first error line, not the whole log: same line, mark it "repeats — likely not the image"; different or clean run, leave it open.
  2. Do not clear a suspicion on one clean run. Inside a staged rollout a clean run only shows that one run passed; it does not show which image ran it. Two separate clean runs on different days are stronger, and still not proof.
  3. Add today's new failures to the same table with the same three words — ordinary, suspicious, destructive — while the logs are fresh. The table is the week's memory; a failure classified today costs a minute, and costs an hour if reconstructed on Friday.
  4. Spend the rest of the pass on the deadline that is no longer next week: macos-14 labels retire on November 2, 2026 — 7 days from today (October 26) — and jobs on them will fail outright. If any workflow still targets macos-14, this is the week it moves; that work has a hard date, unlike the ubuntu-latest rollout, which runs to November 19.

Where my own re-walk stands

I have re-run my scanner (RunnerDriftAudit v0.3.8) against a frozen October 13 baseline on October 20, 21, 22, 23, 24, and 25. All six re-walks reproduced the baseline exactly — 4/2, 4/2, 0/2 across the three targets, no rows moved, no migration-effect rows yet. The scanner reads workflow files, and those files have not changed — Monday's work is on the run side: the checklist, the comparison, and the macos-14 deadline.

Tool

I run these checks with RunnerDriftAudit, a free static scanner for GitHub Actions workflow files (it reads the YAML; it does not execute your jobs, and it cannot see runtime-only behaviour):

Day-8 field note (Gist): https://gist.github.com/alapha888/ebc33e7417417d00b3f1d7112efc9458