Définir les contrôles requis avant fusion

Une modification peut sembler correcte dans votre éditeur tout en laissant un lien interne cassé ou un fichier indispensable absent. Sans critères de validation communs, chaque proposition de fusion est vérifiée différemment et des défauts simples peuvent atteindre la branche principale. Vous allez définir un socle de contrôles que l’équipe pourra appliquer à chaque changement du site.

Définir un socle adapté au dépôt

Un contrôle requis doit répondre à un risque concret, fournir un résultat compréhensible et pouvoir être répété par les membres de l’équipe. Pour ce dépôt de site statique, commencez par vérifier les liens internes de index.html, l’absence d’erreurs de whitespace dans les changements et la présence des fichiers attendus. Ces vérifications ne remplacent pas la revue du contenu ou de la présentation : elles détectent des défauts précis et fréquents.

• Liens internes : chaque lien de la forme #identifiant doit viser un identifiant présent dans la page.
• Intégrité des changements : git diff --check ne doit signaler ni espaces en fin de ligne ni marqueurs de conflit évidents.
• Fichiers du site : index.html et style.css doivent être présents, puisque la page les utilise.
• Vérification de service : le site statique doit pouvoir être servi depuis les fichiers du dépôt, sans dépendance à un fichier absent.

Le contrat du projet fixe les fichiers et la structure que vous devez préserver. La vérification des liens ci-dessous contrôle les références internes de la page d’accueil, sans modifier les fichiers du dépôt et sans installer de dépendance supplémentaire. Exécutez-la depuis la racine du dépôt après avoir placé les changements à vérifier dans votre arbre de travail.

python3 - <<'PY'
from html.parser import HTMLParser
from pathlib import Path
import sys

page = Path("index.html")
if not page.is_file():
    print("ÉCHEC : index.html est absent")
    sys.exit(1)

class Verificateur(HTMLParser):
    def __init__(self):
        super().__init__()
        self.identifiants = set()
        self.fragments = []

    def handle_starttag(self, tag, attrs):
        attributs = dict(attrs)
        identifiant = attributs.get("id")
        if identifiant:
            self.identifiants.add(identifiant)
        href = attributs.get("href", "")
        if href.startswith("#") and len(href) > 1:
            self.fragments.append(href[1:])

verificateur = Verificateur()
verificateur.feed(page.read_text(encoding="utf-8"))
manquants = sorted(set(verificateur.fragments) - verificateur.identifiants)
if manquants:
    print("ÉCHEC : identifiants introuvables : " + ", ".join(manquants))
    sys.exit(1)

print(f"OK : {len(verificateur.fragments)} lien(s) interne(s) vérifié(s)")
PY

git diff --check
test -f index.html && test -f style.css

OK : 4 lien(s) interne(s) vérifié(s)

Le premier contrôle renvoie un code de sortie différent de zéro si un lien interne vise un identifiant absent ; le script indique alors les identifiants à corriger. Les deux commandes suivantes vérifient les changements et la présence des fichiers attendus. Dans un terminal configuré pour arrêter l’exécution au premier échec, vous pouvez les regrouper ainsi : set -e avant la séquence ; un échec interrompt alors le groupe au lieu de laisser croire que tout est passé.

Fixer les critères avant la fusion

Un contrôle est réussi seulement si sa commande se termine sans erreur et si son résultat correspond au critère annoncé. Pour les liens internes, cela signifie qu’aucun fragment ne manque ; pour git diff --check, qu’aucune anomalie n’est signalée ; pour les fichiers attendus, que chacun existe. Si le projet reçoit plus tard une étape de génération, son critère devra être explicite : la commande prévue doit terminer avec succès et produire les ressources attendues.

À ce stade, le dépôt décrit est statique et aucun générateur ni commande de compilation n’est défini dans son contrat. N’inventez donc pas une commande de build qui échouerait faute d’outil configuré : consignez plutôt l’absence de cette étape et vérifiez que les fichiers actuels peuvent être servis. Vous pourrez ajouter un contrôle de génération quand le projet disposera réellement d’un processus de génération documenté.

La liste des contrôles requis doit aussi distinguer les changements concernés. Une modification de page appelle le contrôle des liens et des fichiers ; une modification de documentation peut nécessiter seulement la vérification de whitespace. Cette règle évite d’imposer des vérifications sans rapport tout en maintenant un seuil commun avant fusion. Les modalités d’exécution automatique seront traitées dans la leçon consacrée à l’intégration continue.

À retenir

• Choisissez des contrôles liés aux risques réels du dépôt : liens internes, changements propres et fichiers attendus.
• Définissez pour chaque contrôle un résultat vérifiable et un échec qui bloque la validation.
• Ne déclarez pas de contrôle de génération tant qu’aucune génération n’est configurée et documentée.
• Conservez la distinction entre un contrôle réussi, échoué ou impossible à exécuter.

La prochaine leçon montrera comment faire exécuter ces contrôles dans une intégration continue.