Exécuter les contrôles dans une intégration continue

Vous avez défini les contrôles qui doivent réussir avant une fusion ; il reste à les exécuter de façon régulière, sans dépendre de la mémoire de chaque personne. Une intégration continue lance ces vérifications sur les changements proposés et publie leur résultat dans la revue.

Dans cette leçon, vous configurez un pipeline hébergé, depuis l’interface du service choisi, pour le dépôt du site devenu produit. Cette méthode ne crée pas de fichier de configuration supplémentaire : les seuls fichiers du projet restent index.html, style.css, README.md et .gitignore.

Choisir le déclenchement et préparer l’environnement

Dans les paramètres du dépôt du service d’intégration continue, connectez le dépôt Git, puis créez un pipeline avec déclenchement sur les propositions de fusion visant la branche principale. Si le service propose plusieurs événements, choisissez celui qui lance ou met à jour une vérification à chaque nouvelle proposition et à chaque nouveau commit poussé sur sa branche.

Le pipeline s’exécute dans un environnement de travail temporaire : le service récupère la révision proposée, installe ou sélectionne l’environnement demandé, puis lance les étapes configurées. Pour ce dépôt statique, sélectionnez une version de Python 3 disponible et prévoyez les étapes de contrôle des fichiers, des liens internes et de la possibilité de servir le site. Le dépôt ne possède pas de commande de génération à lancer ; n’en inventez pas une.

Définir les étapes du pipeline

Un pipeline contient un ou plusieurs jobs, c’est-à-dire des groupes d’étapes exécutés dans un environnement défini. Pour commencer, configurez les commandes ci-dessous dans l’ordre, depuis la racine du dépôt. La première vérifie la présence des quatre fichiers convenus ; la suivante utilise le serveur intégré de Python pour confirmer que les fichiers du site peuvent être servis.

test -f index.html && test -f style.css && test -f README.md && test -f .gitignore
python3 -m http.server 8000 --bind 127.0.0.1 > /tmp/depot-http.log 2>&1 & server_pid=$!
sleep 1
curl --fail --silent http://127.0.0.1:8000/ -o /dev/null
resultat=$?
kill "$server_pid" 2>/dev/null || true
wait "$server_pid" 2>/dev/null || true
exit "$resultat"

Dans l’interface du service, placez les commandes dans deux étapes successives : « Vérifier les fichiers attendus » puis « Vérifier le service HTTP ». Le serveur est lancé en arrière-plan, la requête doit recevoir une réponse réussie et le processus est arrêté ensuite. Si une commande échoue, son code de sortie non nul fait échouer l’étape et signale que le pipeline n’est pas validé.

Lire le rapport et relier le statut à la revue

Après l’enregistrement, ouvrez une proposition de fusion de test et vérifiez que le service a bien lancé les étapes sur le commit proposé. Un rapport de statut associe un état, par exemple « réussi » ou « échoué », à cette révision. Un statut réussi signifie uniquement que les commandes configurées ont réussi ; il ne remplace ni la revue de code ni la vérification humaine du contenu.

Dans le service d’hébergement du dépôt, consultez les contrôles publiés pour la proposition et identifiez le nom exact du statut transmis par l’intégration continue. Les contrôles requis avant fusion seront reliés à ces statuts. Leur exigence dans les règles de protection de la branche sera traitée dans une leçon ultérieure ; ici, vous vérifiez que le pipeline s’exécute et que son résultat est visible au bon endroit.

À retenir

• Déclenchez le pipeline sur chaque proposition de fusion et mise à jour de sa branche.
• Découpez les vérifications en étapes explicites, exécutées depuis la racine du dépôt.
• Un code de sortie non nul doit faire échouer le contrôle et rendre le défaut visible.
• Vérifiez le statut publié sur la proposition ; il complète la revue, sans la remplacer.

Dans la leçon suivante, vous aborderez la prévention de l’ajout de secrets à l’historique Git.