DEV Community

alapha888
alapha888

Posted on

Day 4 of the ubuntu-latest rollout: weekly workflows get their first chance at the new image — cadence decides when it reaches you

#githubactions #devops #ci #ubuntu

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 1 covered the workflows that run on every push. Day 3 covered the ones that had not run at all. Day 4 is about cadence: a workflow on a weekly schedule has a first run inside the window, and for a Thursday or Friday schedule that first run is still ahead of you — or happens tonight.

Why cadence decides when this can reach you

The rollout cannot reach a workflow that does not run. Push-triggered workflows had their first chance to land on 26.04 on day 1, and have had many chances since. A workflow that runs every Monday has had at most one scheduled run inside the window, and that run may or may not have landed on the new image. A workflow scheduled for Thursdays has not run at all since the window opened — tonight is its first chance, under whatever your cron line says, quite possibly while nobody is watching.

The same applies to anything rarer: release-only workflows, monthly maintenance jobs, manually dispatched checks. Each has its own first chance, and it is the day it next runs, not October 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 and again on October 21. Both 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 — that part is cadence-independent. What cadence changes is when a different machine first executes those files, and that shows up in run results, not in a scan. That gap between "files unchanged" and "has it actually run on 26.04 yet" is precisely what this cadence check exists to close.

The day-4 check (about 10 minutes)

  1. List your scheduled and dispatch-only workflows — anything that does not trigger on push or pull request. Note each one's next scheduled run.
  2. For the ones that have already run since October 19, compare that run's result against the last pre-October 19 run. A failure that starts exactly at the first post-window run is a rollout candidate, not a coincidence.
  3. For the ones that have not run yet, consider dispatching them manually today, while the pre-migration state is still fresh in mind and both runner images are still in rotation. A controlled first run beats a scheduled surprise.
  4. Keep the macos-14 retirement separate: those labels retire on November 2, 2026 — 11 days from today (October 22) — and jobs on them will fail outright, not drift. Different problem, different fix, same calendar pressure.

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

Top comments (0)