DEV Community

kobima6813
kobima6813

Posted on

How to tell if the ubuntu-latest 26.04 migration broke your build

#githubactions #ubuntu #devops #ci

GitHub is moving the ubuntu-latest label from Ubuntu 24.04 to Ubuntu 26.04. The rollout is gradual and runs between October 19 and November 19, 2026 (GitHub changelog, runner-images announcement #14748).

Because it is gradual, one run can land on 24.04 and the next on 26.04, with no change in your repo. If a build that was green yesterday is red today, this is how to check whether the image is the cause.

1. Check which image the job actually ran on

Open the failed run and expand the Set up job step. You will see something like:

Runner Image
  Image: ubuntu-26.04
  Version: 20261012.163.1
Enter fullscreen mode Exit fullscreen mode

Compare it with the last green run. If the green run says ubuntu-24.04 and the red one says ubuntu-26.04, you have your prime suspect.

The same values are available as environment variables in every job, so you can print them explicitly:

- run: echo "ImageOS=$ImageOS ImageVersion=$ImageVersion" && lsb_release -ds
Enter fullscreen mode Exit fullscreen mode

ImageOS is ubuntu24 or ubuntu26. Logging this in every job makes later debugging much faster.

2. Confirm by pinning (the fastest test)

Re-run the same commit with the old image:

runs-on: ubuntu-24.04   # instead of ubuntu-latest
Enter fullscreen mode Exit fullscreen mode
  • Green on 24.04 and red on 26.04 means the image change is the cause.
  • Red on both means the cause is something else (a dependency release, a flaky test, your own change).

Pinning to ubuntu-24.04 is also the officially suggested escape hatch if you are not ready to move. Treat it as a temporary pin, not a permanent fix.

To test ahead of time, add a matrix leg:

strategy:
  matrix:
    os: [ubuntu-24.04, ubuntu-26.04]
runs-on: ${{ matrix.os }}
Enter fullscreen mode Exit fullscreen mode

3. Diff the installed software

Each image has a software list in actions/runner-images:
Ubuntu2404-Readme.md and Ubuntu2604-Readme.md. Diff them for the tools your build uses, and check the releases page for the exact ImageVersion you got.

Differences we saw when comparing the two READMEs on 2026-10-20 (always re-check against the current files):

Area Ubuntu 24.04 Ubuntu 26.04
Default Python 3.12 3.14
Default Node.js 22 24
Ruby / PHP / Perl 3.2 / 8.3 / 5.38 3.3 / 8.5 / 5.40
Clang 16–18 20–22
OpenSSL 3.0 3.5
Docker client 28 29
Kernel 6.x azure 7.0 azure
Java 8 (JAVA_HOME_8_X64) present not listed
Not listed on 26.04 Fastlane, Julia, Lerna, Mercurial, Miniconda, Newman, Parcel, Pulumi, MediaInfo, Haveged, Sphinx search server

4. Common breakages and quick fixes

  • "command not found" for a tool that used to be preinstalled: install it explicitly (setup-* action, apt-get install, pip/npm install) instead of relying on the image.
  • Python 3.14 / Node 24 default changes: pin the version with actions/setup-python / actions/setup-node rather than using whatever the image ships. Watch for removed stdlib/deprecated APIs and native modules that have no wheels/prebuilds yet.
  • Compiler upgrades (newer GCC/Clang): new warnings become errors under -Werror; old code may need flag changes.
  • OpenSSL 3.5: legacy algorithms or old TLS settings in tests can fail.
  • Java 8 missing: use actions/setup-java with java-version: 8.
  • apt package names changed or removed: apt-get install fails with "Unable to locate package". Check the package name for 26.04 (resolute).
  • Kernel / system changes: low-level things (eBPF, ACLs, FUSE, container runtimes) can behave differently. One example reported on day 2 of the rollout: setfacl fails on Ubuntu 26.04 (#15004).
  • Cache keys: if your cache key does not include the OS version, a 24.04 cache restored on 26.04 can break native builds. Include ${{ runner.os }}-${{ env.ImageOS }} in the key.

If you find a real regression in the image, search and report it in actions/runner-images issues with the ImageVersion from step 1.

5. Tell "it's the image" from "it's just me" across repos

The hard part in a gradual rollout is knowing whether a red build is your problem or everybody's. Disclosure: I built a small free tool for this, CI Early-Warn. A GitHub Action reports minimal job metadata (OS, image version, pass/fail, failing-step category; no code, logs or repo names). When failures across many repos jump on a new image version, it raises an alert, and says "ambiguous" when it can't tell the cause. It is early and only useful with enough participants, so steps 1–4 above are the reliable method.

TL;DR

  1. Look at Set up job → Runner Image (or $ImageOS / $ImageVersion).
  2. Re-run with runs-on: ubuntu-24.04.
  3. Diff the runner-images READMEs for the tools you use.
  4. Install/pin what you depend on explicitly, then move to 26.04 on your schedule.

Top comments (0)