Day 10 of the ubuntu-latest rollout: Wednesday - turn Tuesday's isolation result into a decision

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 9 held the image still: the same job ran once on the explicit ubuntu-24.04 label and once on the explicit ubuntu-26.04 label, so the result separated the image from the code.

Day 10 is Wednesday: an isolation result is not a fix. Today it becomes a decision, while there are still two ordinary working days left this week to act on it.

What each isolation outcome asks for

If the job failed on both explicit labels with the same error, the image is cleared - treat it as a normal bug in the workflow, fix it in the code, and take it off the rollout list entirely. It was never drift, and keeping it on the list makes the list less trustworthy.

If it failed on only one label, that is the first confirmed drift of the window, and it forces a choice rather than another observation: pin the job to ubuntu-24.04 and ride out the window on the image you know, or move it to ubuntu-26.04 now and fix the incompatibility while the old image is still available for comparison. Either choice is defensible; leaving the job on the floating label after you have proof is not.

If it passed on both labels, the original failure was most likely the sampling noise of the staged rollout itself - close the entry, but write down that it was closed by isolation, not by a lucky clean re-run.

The 15-minute Wednesday pass

• Take Tuesday's isolation result for the one suspicion you isolated and write the decision next to it in one line: "not the image - fix as a normal bug", "confirmed drift - pinning to 24.04", or "confirmed drift - moving to 26.04 and fixing". A result without that line is still just watching.
• If you pinned, set the explicit label in the workflow and note the date you intend to revisit it - after November 19, when the rollout window closes. A pin without a revisit date becomes a permanent surprise for whoever maintains the workflow next year.
• If you moved forward, keep the failing step name and first error line from the isolation run at the top of the fix list. That line is the evidence; a fix that starts from a fresh, possibly different failure has thrown the evidence away.
• Spend what is left on the hard deadline inside this week: macos-14 labels retire on November 2, 2026 - 5 days from today (October 28) - and jobs on them will fail outright, not drift. Wednesday is the last calm day to move a macos-14 job and still have Thursday and Friday to watch it run; a move made on Friday is verified, if at all, over an unattended weekend, and Monday is the retirement day itself.

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, 25, and 26. All seven 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 October 27 re-walk was not run.

The scanner reads workflow files, and those files have not changed - Wednesday's work is on the decision side: one isolation result turned into a pin, a move, or a normal bug fix, and the macos-14 deadline now five days out.

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):

• Repo: https://github.com/alapha888/runner-drift-audit
• Current release: v0.3.8 (October 20, 2026)
• Multi-repo edition (one combined report for a whole local workspace), $29 one-time: https://alapha888.gumroad.com/l/mepra

Day-10 field note (Gist): https://gist.github.com/alapha888/2058ecb0eb78668a095051d2092e17a8