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 6 covered Saturday: record the weekend runs while the logs still exist. Day 7 is Sunday, the last quiet day of the first rollout week: the useful work today is turning that raw weekend log into the short checklist Monday morning starts with.

What Sunday can settle, and what it cannot

Sunday cannot tell you which image a weekend run used, and it cannot prove a failure was image-caused. What it can do is remove Monday's guesswork: every weekend failure already classified as "ordinary", "suspicious", or "destructive — checked already" means Monday's first runs get compared against a table, not against memory. The staged rollout runs to November 19, so this comparison habit is the thing that compounds — not any single day's result.

The 10-minute Sunday pass

  1. Go through the weekend log from Day 6. For each failure, write one word next to it: ordinary (fails the same way on any image), suspicious (behaviour you have not seen before this week), or destructive (deploy, release, data job — those were already checked on the day, per Day 6).
  2. For each "suspicious" failure, keep the workflow name and the first error line at the top of Monday's list. Monday's first matching run is the comparison: same error on a new run means it was probably never the image; a clean run means you still know nothing — the re-run may have landed on the other image.
  3. Do not "fix" a suspicious failure today by re-running it until it passes. A green re-run erases the evidence and proves nothing about either image. If the job matters, pin the investigation, not the conclusion.
  4. Check the calendar item that is not a drift question at all: macos-14 labels retire on November 2, 2026 — 8 days from today (October 25) — and jobs on them will fail outright. If any workflow still targets macos-14, that migration is a deadline task for this week, separate from the ubuntu-latest rollout.

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, and 24. All five 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 — Sunday's work is on the run side: a log, a classification, and a Monday checklist.

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-7 field note (Gist): https://gist.github.com/alapha888/558b74a698e5e2eb835c9bdd88be7d8e