Day 9 of the ubuntu-latest rollout: stop watching the open suspicions and isolate one
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 8 used Monday's first weekday runs to narrow the weekend's suspicious list: failures that repeated were probably never the image, and the rest stayed open. Day 9 is Tuesday: an open suspicion that survives two days of watching will not settle by being watched a third day. Today one of them gets isolated properly, by holding the image still.
The one comparison that actually separates the variables
Every comparison so far has had the same flaw: a re-run of the same workflow may land on either image, so a pass and a fail are both ambiguous. The fix is to stop sampling the floating label and run the comparison yourself. Take the workflow behind your most expensive open suspicion and run the same job twice, once on the explicit ubuntu-24.04 label and once on the explicit ubuntu-26.04 label — as a temporary test job or a manual dispatch on a branch, not by editing the production workflow. Same code, same inputs, two named images. If it fails on both, the image is cleared and the bug is yours. If it fails on only one, you have the first real drift evidence of the window, with the failing step and error line already captured. Either outcome closes an entry that passive watching would have carried for another week.
The 15-minute Tuesday pass
- Pick exactly one open suspicion — the one whose failure would cost the most if it reached a release. Isolating all of them today is a project; isolating one is fifteen minutes, and the method transfers to the rest.
- Run it on both explicit labels and record the two results next to the original entry: same error on both means "not the image — investigate as a normal bug"; an error on one only means "first confirmed drift — keep the step name and first error line at the top of the list".
- Remove the temporary comparison job afterwards, or leave it clearly marked as a test. A leftover duplicate job in a production workflow becomes next month's unexplained failure.
- Spend what is left on the deadline inside this week: macos-14 labels retire on November 2, 2026 — 6 days from today (October 27) — and jobs on them will fail outright, not drift. A workflow still on macos-14 on Friday has a weekend and a Monday morning left; that is the wrong shape for a migration with a hard date.
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 scanner reads workflow files, and those files have not changed — Tuesday's work is on the run side: one controlled comparison, and the macos-14 deadline now inside a single week.
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-9 field note (Gist): https://gist.github.com/alapha888/bc1feda9d03dcf3658930f824a5265f0
Top comments (0)