Qualité, versions et GitHub Actions

1. Un dépôt compréhensible pour les autres

Un README utile explique ce que fait le projet, comment le lancer et comment le vérifier. Pour NKILItech, il doit permettre à une nouvelle personne de comprendre le portail sans demander où se trouve chaque fichier. Ajoutez les prérequis et les limites connues.

Une licence précise les conditions de réutilisation ; rendre un dépôt public ne suffit pas à choisir une licence. Un document de contribution explique la démarche attendue. De gros fichiers binaires ou des jeux de données volumineux demandent une stratégie adaptée, éventuellement Git LFS, plutôt qu’une accumulation de versions ordinaires.

Les dépendances générées peuvent être exclues, tandis que les fichiers de verrouillage utiles à une installation reproductible sont généralement conservés selon l’écosystème. Il faut distinguer les résultats reconstruisibles des sources nécessaires pour les obtenir.

2. Secrets : exclure, vérifier et réagir

Le modèle .env.example documente les variables attendues avec des valeurs factices. Le véritable .env reste local. Avant publication, vérifiez les fichiers préparés et les exemples de configuration ; un dépôt privé n’est pas un coffre-fort adapté à tous les secrets.

git check-ignore -v .env
git ls-files -- .env
git diff --cached

Si .env est déjà suivi, une suppression du suivi peut se préparer avec git rm --cached -- .env, en vérifiant que le fichier local est conservé puis en ajoutant une règle d’exclusion. Cette action ne retire pas ses anciennes versions de l’historique.

Lorsqu’un secret a été exposé, la première mesure est sa révocation ou sa rotation auprès du service concerné. Supprimer le fichier dans un nouveau commit ne rend pas l’ancien secret sûr. Le nettoyage d’historique et la coordination des clones constituent ensuite un travail spécifique.

3. Tags et releases

git tag -a v1.0.0 -m "Première version du portail pédagogique"
git show v1.0.0
git push origin v1.0.0

Une étiquette, ou tag, désigne un point de l’historique. Une étiquette annotée possède ses propres informations et un message. Contrairement à une branche de développement, elle sert généralement de repère stable pour une version.

Une release GitHub ajoute une présentation de livraison autour d’un tag, avec des notes et éventuellement des fichiers distribués. Les notes décrivent les changements utiles aux utilisateurs et les limites connues. Déplacer silencieusement un tag déjà publié rend les références ambiguës ; une nouvelle version est souvent plus lisible.

Une convention de version peut distinguer changements incompatibles, ajouts compatibles et corrections. Elle doit correspondre aux engagements du projet ; écrire v1.0.0 ne prouve pas à lui seul qu’un produit est terminé ou vérifié.

4. Une automatisation qui contrôle vraiment quelque chose

GitHub Actions exécute des workflows définis dans .github/workflows/. Un événement déclenche un workflow, qui contient des jobs exécutés sur des runners ; chaque job regroupe des étapes. Une vérification automatique doit échouer si la propriété contrôlée est fausse.

Pour notre petit portail statique, ajoutons un script Python indépendant d’un framework. Il vérifie deux fichiers attendus, leur contenu non vide et la présence d’un titre de premier niveau dans l’accueil.

from pathlib import Path

required = ("README.md", "index.html")
for name in required:
    path = Path(name)
    if not path.is_file() or not path.read_text(encoding="utf-8").strip():
        raise SystemExit(f"Fichier manquant ou vide : {name}")

page = Path("index.html").read_text(encoding="utf-8").lower()
if "<h1" not in page:
    raise SystemExit("Un titre h1 est attendu dans index.html")
print("Vérifications du portail réussies")

Enregistrez ce code dans scripts/check_portail.py et exécutez python scripts/check_portail.py à la racine du laboratoire. Il s’agit d’un contrôle minimal de structure ; il ne valide pas toute l’accessibilité ni la qualité de la page.

5. Définir et lire le workflow

Créez .github/workflows/verification.yml. L’exemple utilise les versions majeures ci-dessous ; pour un dépôt de production, relisez les versions et les recommandations du projet de chaque action, puis utilisez des références immuables quand la politique l’exige.

name: Vérifier le portail

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  verifier:
    runs-on: ubuntu-latest
    steps:
      - name: Récupérer le dépôt
        uses: actions/checkout@v7
      - name: Préparer Python
        uses: actions/setup-python@v7
        with:
          python-version: "3.12"
      - name: Contrôler les fichiers
        run: python scripts/check_portail.py

Le workflow s’exécute lors d’un push sur main et pour les pull requests ciblant main. Le job utilise un environnement hébergé, récupère le dépôt, prépare Python puis lance le script. Sans l’étape de récupération, les fichiers du projet ne seraient pas automatiquement présents dans le runner.

La permission contents: read suffit à cet exemple ; il n’a pas à modifier le dépôt. Aucun secret n’est nécessaire. Des workflows déclenchés depuis des contributions externes doivent être conçus en tenant compte du code exécuté et des permissions accordées.

6. Du contrôle réussi à la livraison

Une équipe peut exiger certains contrôles et une revue avant fusion grâce aux règles disponibles pour son dépôt. Le nom du contrôle attendu doit correspondre à un job effectivement exécuté ; une règle exigeant un contrôle qui ne se lance jamais peut bloquer l’intégration.

Une intégration continue vérifie régulièrement les changements. Un déploiement continu ajoute la mise à disposition sur un environnement. Notre workflow se limite au contrôle du portail : il ne publie pas de site et ne modifie pas un serveur.

Avant une release, relisez les changements depuis la version précédente, vérifiez le résultat, préparez les notes et identifiez clairement le commit livré. Les schémas et le journal Git deviennent alors des supports pour expliquer ce qui a changé.

Exercices corrigés