Day 6 of the ubuntu-latest rollout: the weekend runs are happening now, unattended

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 5 covered Friday: dispatch the important weekend jobs manually while someone is watching. Day 6 is Saturday: the first fully unattended runs of the window are now happening, and the question changes from "can I test early?" to "what do I record today so Monday's check is a comparison, not a reconstruction?"

What a Saturday run can and cannot tell you

A weekend schedule that fires today is running on one of the two images still in rotation. A green result does not prove it ran on 26.04, and a red result does not prove the image caused it — weekend jobs also fail for the ordinary reasons they always fail. The value of today is not a verdict. It is a timestamped record: which workflows ran, at what time, and with what result, captured while the run logs still exist and before Monday's runs overwrite the recent history you will compare against.

The 5-minute Saturday log (do this today, not Monday)

  1. List every workflow that ran or will run this weekend. For each one, note the run time and the result — pass, fail, or did not run. Two lines per workflow is enough; you are building Monday's comparison table, not writing a report.
  2. If a weekend job failed, save the failing step name and the first error line now. Do not re-run it yet to "see if it passes" — a re-run may land on the other image and erase the only evidence of which behaviour you actually saw.
  3. If a weekend job is destructive on failure — a deploy, a release, a data job — that is the one exception: check it today rather than logging it for Monday. Everything else can wait; a bad deploy cannot.
  4. Keep the macos-14 retirement separate: those labels retire on November 2, 2026 — 9 days from today (October 24) — and jobs on them will fail outright, not drift. A Saturday job on macos-14 is not a rollout candidate; it is a deadline.

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, and 23. All four 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 — what this weekend changes is execution, not files. That is why today's useful work is a run log, not another scan.

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