Garder l'IC et les vérifications locales identiques : un point d'entrée unique, des outils figés, le même conteneur

Objectif

Une vérification qui passe en local passe en IC, et inversement, de sorte que les commits « fix lint », les échecs propres à l'IC et les disputes du type « ça marche chez moi » disparaissent, et qu'un agent puisse faire confiance à son exécution locale comme prédiction du pipeline.

Prérequis

Un point d'entrée de lanceur de tâches pour chaque vérification (voir l'article associé), un manifeste de version pour la chaîne d'outils, et un service d'IC capable d'exécuter une image de conteneur de son choix. GitHub Actions documente l'exécution des étapes d'un job à l'intérieur d'un conteneur déclaré avec container: et une image: ; asdf lit les versions d'outils depuis un fichier .tool-versions et installe tout ce qui y figure avec asdf install ; mise lit le même fichier ou un mise.toml avec une section [tools].

Étapes

1. Définir chaque vérification une seule fois comme une tâche nommée (lint, typecheck, test, build) et faire en sorte que le workflow d'IC n'appelle que ces noms, rien d'autre. Là où l'IC a besoin d'un comportement différent (pas de mode veille, sortie exploitable par une machine), ajouter un indicateur que la tâche accepte plutôt qu'une seconde commande.
2. Figer la chaîne d'outils dans un manifeste versionné dans le dépôt (.tool-versions, mise.toml, ou le Dockerfile du conteneur de développement) et faire en sorte que l'amorçage local et le job d'IC installent tous deux à partir de lui ; jamais latest.
3. Exécuter l'IC à l'intérieur de la même image de conteneur que celle utilisée par l'environnement de développement, ou construire l'image en IC à partir du même Dockerfile, afin que les paquets du système d'exploitation correspondent aussi.
4. Figer les outils qui effectuent les vérifications (formateur, linter, lanceur de tests) dans le fichier de verrouillage du projet plutôt qu'en installations globales, et les invoquer via la tâche, de sorte que la version verrouillée soit la seule qui puisse s'exécuter.
5. Supprimer les différences environnementales : éviter les chemins de code qui se comportent différemment quand une variable CI est définie, fixer la locale et le fuseau horaire à l'intérieur de la tâche (LC_ALL=C.UTF-8, TZ=UTC), et rendre les caches optionnels plutôt qu'obligatoires.
6. Ajouter un job planifié qui exécute l'ensemble complet des vérifications depuis un clone propre dans le conteneur, sans aucun cache ; il attrape les vérifications qui ne passent en local qu'à cause d'un état résiduel.
7. Quand l'IC échoue et que le local passe, traiter la différence comme le bug : consigner l'écart (version, variable d'environnement, fichier manquant) et l'éliminer avant de corriger le symptôme.

Résultat attendu

Le fichier de workflow est court : checkout, installation depuis le manifeste, exécution des tâches nommées. Une personne contributrice reproduit tout échec d'IC avec le même nom de commande, et le temps d'IC va aux vérifications plutôt qu'à la dérive de configuration.

Limites et base de vérification

Le comportement dépendant du matériel (nombre de CPU, limites de mémoire, GPU) diffère encore et se manifeste dans les tests sensibles au minutage. Les secrets et identifiants de service diffèrent par conception ; les vérifications qui en ont besoin n'appartiennent pas à l'ensemble de parité. Il s'agit d'une procédure proposée fondée sur la documentation citée ; aucun chiffre de taux de défaut n'est revendiqué.

Exécuter les vérifications en mode IC des deux côtés

De nombreux outils changent déjà de comportement quand la variable d'environnement CI est définie : les lanceurs de tests arrêtent d'écrire de nouveaux instantanés et désactivent le mode veille, les gestionnaires de paquets refusent de modifier le fichier de verrouillage, et les configurations de test généré interdisent les tests ciblés. Ces branches ne peuvent pas être supprimées, la règle de parité est donc l'inverse de leur évitement : la tâche qui exécute l'ensemble des vérifications exporte elle-même CI=true, de sorte que l'exécution locale et le pipeline empruntent les mêmes branches dans chaque outil tiers. Le code propre du projet ne devrait quant à lui jamais se brancher sur CI. Une vérification qui passe sans la variable et échoue avec elle devient alors reproductible en local avec la même commande.