Le label ubuntu-latest migre vers Ubuntu 26.04 et casse les builds qui ne pinent rien

17 septembre 2026. GitHub annonce que le label ubuntu-latest quitte Ubuntu 24.04 pour Ubuntu 26.04. 19 octobre au 19 novembre 2026. Le basculement se fait progressivement, machine par machine, sur une fenêtre d’un mois. JDK 17 → 25. Le runtime Java par défaut saute deux générations, et Docker Compose, Helm et CMake franchissent chacun une version majeure. Pourquoi c’est important : un workflow qui écrit runs-on: ubuntu-latest et qui fait confiance au « peu importe ce que GitHub me donne » va, cette fois, casser — sans que personne n’ait changé une ligne du dépôt.

Ce que cette migration a de différent

GitHub livre une nouvelle image de runner à chaque LTS d’Ubuntu, et la plupart du temps personne ne le remarque parce que ubuntu-latest vous porte silencieusement. Ce qui rend cette édition particulière, c’est l’ampleur des sauts internes. Ce n’est pas un rafraîchissement de niveau correctif, c’est une bascule de version majeure doublée d’une suppression d’outils, et la fenêtre de déploiement est progressive : pendant un mois, deux exécutions simultanées de la même pipeline peuvent tourner l’une sur 24.04 et l’autre sur 26.04, sans le moindre changement de votre côté.

Le tableau des changements, vérifié contre les manifestes officiels de actions/runner-images, donne la mesure du saut :

Le saut du JDK de 17 à 25 est celui qui frappera le plus de monde en premier, parce qu’une grande partie des builds Maven et Gradle n’épinglent pas explicitement une version de Java et se contentent de ce que JAVA_HOME pointe. Docker Compose et Helm franchissent eux aussi une frontière majeure, ce qui se traduit généralement par des changements de drapeaux CLI et de schéma de fichier — pas par un simple changement de numéro.

Les outils qui disparaissent, et les paquets qui changent de nom

La partie la plus sournoise n’est pas la mise à jour, c’est la disparition. Ces outils sont présents sur ubuntu-24.04 et simplement absents de ubuntu-26.04 : un job qui en dépend échouera avec un command not found, sans avertissement préalable :

• Java 8 — seuls 11, 17, 21 et 25 sont désormais livrés
• Miniconda — la variable CONDA est présente mais vide
• Swift, Julia, Pulumi, Fastlane, Mercurial, Newman, Parcel, Lerna, MediaInfo, Sphinx

Deux noms de paquets apt changent aussi : p7zip-full et p7zip-rar deviennent 7zip et 7zip-rar, et dnsutils devient bind9-dnsutils. Un step qui fait un apt-get install -y p7zip-full ou dnsutils explicite cassera sur 26.04, alors que la fonctionnalité sous-jacente existe toujours sous un autre nom.

Le piège est le silence. Une image qui perd Java 8 ne prévient pas : le build échoue au moment de la compilation, des semaines après l’annonce, sur un runner que vous n’avez pas choisi de changer.

Les runners auto-hébergés restent hors de portée

Une clarification importante avant de paniquer : cette migration ne concerne que les runners hébergés par GitHub. Un runner auto-hébergé s’enregistre avec ses propres labels — self-hosted, Linux, le nom de votre pool — et le label ubuntu-latest y est soit absent, soit défini par vous. GitHub ne va pas mettre à jour l’OS d’une machine que vous administrez : si votre runner auto-hébergé tourne sous 24.04, il restera sous 24.04 jusqu’à ce que vous le reprovisionniez.

La confusion vient d’un cas particulier : les équipes qui reproduisent les images officielles de GitHub sur leurs propres runners, via des images miroir ou des agents installés sur des VM Ubuntu. Celles-là bougent quand vous les bougez, pas quand GitHub bascule son label. Le point de vigilance reste donc la version d’outils : si votre runner auto-hébergé embarque un JDK 17 et que votre build s’y fie, la migration de GitHub ne vous sauvera ni ne vous cassera — c’est votre image qui décide.

Repérer les workflows exposés avant le 19 octobre

L’audit commence par une question simple : combien de vos dépôts écrivent ubuntu-latest — ou, pire, ne précisent rien du tout ? La recherche de code de GitHub répond en une requête, et un script local fait le tour d’une organisation :

# Compter les usages de ubuntu-latest dans un clone local d’une organisation :
grep -Rl "runs-on: ubuntu-latest" --include="*.yml" --include="*.yaml" . 2>/dev/null | wc -l

# Repérer aussi les workflows qui ne précisent AUCUN runs-on (défaut implicite) :
grep -RL "runs-on:" --include="*.yml" --include="*.yaml" . 2>/dev/null

Le second cas est le plus dangereux : un workflow sans runs-on: hérite d’un défaut implicite qui, lui aussi, finira par pointer vers 26.04. La liste obtenue est votre périmètre de test entre maintenant et le 19 octobre, ni plus, ni moins.

Deux options, et une seule bonne pratique de fond

Entre aujourd’hui et le 19 octobre, vous avez exactement deux options responsables. Ne rien faire en espérant n’en fait pas partie, puisque le déploiement est progressif et non déterministe de votre point de vue.

Option A — épingler l’image actuelle si vous n’êtes pas prêt. Il suffit de remplacer le label par la version explicite :

jobs:
  build:
    runs-on: ubuntu-24.04   # au lieu de ubuntu-latest
    steps:
      - uses: actions/checkout@v4

Option B — tester la nouvelle image maintenant avec ubuntu-26.04, idéalement en matrice pour comparer les deux pendant la transition :

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-24.04, ubuntu-26.04]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4

Mais l’épinglage du runner ne règle que le symptôme. La bonne pratique de fond, celle qui survit à toutes les migrations, est d’épingler les runtimes eux-mêmes via les actions dédiées — actions/setup-java, actions/setup-python, actions/setup-node — plutôt que de faire confiance au défaut système. Un build qui déclare explicitement java-version: 21 ne bouge pas, que le label du runner pointe vers 24.04 ou 26.04.

La nuance Java 8 : setup-java continue de fonctionner

Un point mérite d’être dit clairement, parce qu’il évite une fausse urgence : la suppression de Java 8 ne concerne que le défaut système de l’image. Si vos builds obtiennent Java 8 via actions/setup-java avec java-version: 8, ils continueront de fonctionner sur 26.04 — l’action télécharge son propre JDK, indépendamment de ce que l’image préinstalle. La casse ne touche que les workflows qui invoquent le java système et supposent qu’il pointe vers la version 8.

C’est la même logique pour Miniconda : les équipes qui l’utilisaient via la variable CONDA préinstallée devront installer leur environnement explicitement, mais celles qui passaient déjà par conda-incubator/setup-miniconda ne verront rien. La frontière n’est pas « l’outil disparaît », elle est « l’outil préinstallé disparaît » — et tout ce qui se provisionne via une action de setup reste intact. C’est une raison de plus d’épingler les runtimes avec setup-* plutôt que de dépendre du contenu de l’image : la couche qui vous protège des migrations est celle que vous contrôlez explicitement.

Verdict

Si vos workflows reposent sur le défaut système — JAVA_HOME, python, node sans action de setup — vous avez une échéance : le 19 octobre, premier jour de la fenêtre de bascule. Épinglez ubuntu-24.04 le temps de stabiliser, puis testez ubuntu-26.04 en matrice avant que le label ne bascule tout seul. Si vous dépendez d’un outil supprimé — Java 8, Miniconda, Pulumi, Fastlane, Newman — le pin vers ubuntu-24.04 n’est qu’un sursis : la disparition est définitive, et il faut migrer l’outillage ou l’installer explicitement dans le job. Si vous avez déjà épinglé vos runtimes via setup-*, vous êtes l’exception qui dormira tranquille : la migration se fera sous vous sans effet visible. La règle tient en une phrase : un label latest est un curseur mouvant, et tout ce qui n’est pas épinglé finit par se faire déplacer par quelqu’un d’autre.

Références

• GitHub Changelog — Ubuntu 26 generally available and latest migration (17 septembre 2026)
• Cloudkaramchari — GitHub Actions Ubuntu 26.04 Migration: What Breaks When ubuntu-latest Moves (19 septembre 2026)
• GitHub — actions/runner-images (manifestes logiciels officiels des images)