Transition vers Ubuntu 26.04 sur GitHub Actions : identifier d'abord les différences d'exécuteurs sur un même commit
Les résultats de votre CI peuvent changer sans la moindre modification du code source. Si vos workflows reposent sur ubuntu-latest, la transition de l'image du système d'exploitation doit faire partie des changements gérés par votre équipe.
GitHub a annoncé la prise en charge officielle des exécuteurs Ubuntu 26.04 et le plan de migration d'ubuntu-latest pour le 17 septembre 2026. Cet article ne prétend pas que la nouvelle image est intrinsèquement plus rapide, mais propose une approche pratique pour isoler et identifier les différences d'environnement à partir d'un même commit.
Périmètre confirmé dans l'annonce officielle
D'après l'annonce, les images Ubuntu 26.04 sont officiellement prises en charge sur x64 et arm64, avec les étiquettes explicites ubuntu-26.04 et ubuntu-26.04-arm. ubuntu-latest migrera progressivement d'Ubuntu 24.04 vers 26.04 entre le 19 octobre et le 19 novembre 2026.
La nouvelle image comportant des outils mis à jour ou supprimés, les builds dépendant de packages préinstallés peuvent être affectés. Si votre équipe n'est pas prête, GitHub recommande de spécifier explicitement ubuntu-24.04. Ce calendrier ne correspond pas nécessairement à la date de bascule effective de chaque dépôt individuel.
Documenter l'environnement attendu par votre dépôt
Commencez par vérifier la directive runs-on dans vos workflows et workflows réutilisables. Ne partez pas du principe que l'utilisation de conteneurs élimine tout impact de l'hôte : examinez également les étapes d'installation, d'archivage et de téléversement exécutées en dehors des conteneurs.
Dressez une liste de contrôle séparant compilateurs, environnements d'exécution, gestionnaires de paquets et bibliothèques système. Au lieu de simplement noter le nom d'un outil, reliez son origine d'installation à l'étape qui l'appelle, ce qui facilitera l'identification des causes dans les journaux d'erreurs.
Même commit, deux environnements, artefacts distincts
Pour des tests plus clairs, effectuez ces exercices de transition sur un chemin d'exécution dépourvu d'autorisations de déploiement. Exécutez le même commit et les mêmes fichiers de verrouillage sur l'ancienne et la nouvelle image, puis conservez séparément les journaux, les résultats des tests et les noms d'artefacts. Il s'agit de la méthode de vérification proposée dans cet article.
Lors de la comparaison initiale, notez les conditions de mise en cache afin de distinguer l'impact d'un cache obsolète. En plus du succès ou de l'échec du build, conservez les versions des outils installés, les étapes en échec et les résultats d'exécution des artefacts pour repérer les réussites fortuites dues à un simple hit de cache.
La vérification au-delà de la coche verte
Pour un projet web, vous pouvez vérifier si les fichiers générés sont réellement exploitables en production et, en présence de dépendances natives, vous assurer qu'elles se chargent correctement dans l'environnement cible. Plutôt que d'exiger une identité binaire absolue pour tous les artefacts, séparez les variations non déterministes (comme les horodatages) des véritables divergences fonctionnelles.
Les réviseurs doivent avoir accès au même endroit aux liens des exécutions sur la nouvelle image, aux écarts de versions d'outils, aux résultats des tests de fonctionnalités clés et aux changements à annuler en cas de besoin. Associer la migration d'un exécuteur à un refactoring applicatif élargit inutilement la recherche des causes d'échec et le périmètre d'un rollback.
Avantages et limites du verrouillage d'image
Définir une étiquette de système d'exploitation explicite aide à maîtriser les transitions majeures, mais ne garantit pas un environnement de build entièrement immuable. Conservez la bonne pratique consistant à installer explicitement les outils nécessaires à l'exécution et à consigner leurs versions réelles dans les journaux.
Pour les petits dépôts, il n'est pas nécessaire de mettre en place une infrastructure de validation massive. Vous pouvez commencer par comparer un seul build représentatif et les dépendances les plus sensibles, et en cas de verrouillage temporaire, consigner le responsable du déverrouillage ainsi que la date de réévaluation prévue.
Distinguer les débats publics des décisions de l'équipe
Les issues publiques de runner-images constituent un canal utile pour suivre les modifications d'images et les signalements de problèmes. Cependant, un commentaire isolé ou l'échec d'un autre projet ne signifie pas que le problème se reproduira dans votre dépôt, et cet article ne formule aucune affirmation chiffrée sur le consensus de la communauté ou la fréquence des incidents.
L'action du jour consiste à localiser les occurrences de l'étiquette latest et à tester le même commit sur la nouvelle image. En définissant préalablement les critères de validation et de suspension, les responsables pourront s'appuyer sur des preuves concrètes si les builds viennent à différer lors de la transition réelle.