Automatiser les tests avec la CI intégrée¶

Objectifs¶

À la fin de ce tutoriel, tu sauras :

• O1. Écrire un fichier .gitrust-ci.yml minimal en mode Easy pour un projet Rust ou Node
• O2. Déclencher un pipeline CI en poussant un commit
• O3. Lire le résultat d'un pipeline (statut, logs) sur la page /{owner}/{repo}/ci

Pré-requis¶

• Technique : dépôt cloné en local avec au moins un fichier source (tutoriel 02 complété), Git installé
• Pédagogique : tutoriel 03 — Collaborer complété
• Temps estimé : ~20 minutes

Vue d'ensemble¶

La CI (Continuous Integration, intégration continue) automatise l'exécution de tes tests à chaque push. Au lieu de vérifier manuellement que le code compile et que les tests passent, gitrust le fait pour toi — et signale immédiatement si quelque chose est cassé.

Le mode Easy de gitrust CI utilise un fichier .gitrust-ci.yml que tu places à la racine de ton dépôt. Ce fichier décrit en quelques lignes ce que gitrust doit exécuter : compiler, linter, tester. Le serveur de build reçoit le code, l'exécute dans un container Docker isolé, et renvoie les logs en temps réel.

flowchart LR
    subgraph "Ta machine"
        C[Commit +
git push]
    end
    subgraph "gitrust (:4000)"
        W[CiWorker
Tokio task]
        DB[(Pipeline
en base)]
    end
    subgraph "Serveur de build"
        D[Docker
+ Dagger]
        CI[ci-engine]
    end

    C -->|push SSH/HTTP| W
    W --> DB
    W -->|rsync + SSH| D
    D --> CI
    CI -->|logs ligne par ligne| W
    W --> DB
    DB -->|SSE stream| C

Scaffolding niveau 2 : la configuration CI comporte une section incomplète à compléter. Essaie d'abord sans regarder l'indice.

Étape 1 : Vérifie que la CI est activée sur le dépôt¶

Dans ton navigateur, ouvre ton dépôt et navigue vers Settings (/{owner}/{repo}/settings).

Fais défiler jusqu'à la section CI. Si tu ne vois pas cette section, l'administrateur de l'instance n'a pas encore activé le CI — contacte-le.

Coche CI activé et Déclencher sur push. Clique Enregistrer.

Checkpoint : la case CI activé est cochée et sauvegardée. Si la section CI n'apparaît pas dans les paramètres, la fonctionnalité n'est pas activée sur cette instance — consulte la section « Et si ça ne marche pas ».

Étape 2 : Crée le fichier .gitrust-ci.yml¶

Dans ton terminal, depuis la racine du dépôt cloné, crée le fichier de configuration CI.

Pour un projet Rust :

# .gitrust-ci.yml
language: rust

build:
  command: "cargo build"

checks:
  lint: "cargo clippy -- -D warnings"
  format: "cargo fmt -- --check"

tests:
  command: "___"

Complète ___ avec la commande de test Rust standard. Réponse : cargo test.

Pour un projet Node.js :

# .gitrust-ci.yml
language: node

build:
  command: "npm install"

checks:
  lint: "npm run lint"

tests:
  command: "npm test"

Pour ce tutoriel, utilise le fichier le plus adapté à ton projet, ou crée un exemple minimaliste avec Node si tu n'as pas de projet existant :

# Exemple minimal Node — crée les fichiers nécessaires
echo '{"name":"demo","scripts":{"test":"node -e \"console.log(42===42)\"","lint":"echo ok"}}' > package.json

Puis crée .gitrust-ci.yml avec le contenu Node ci-dessus.

Checkpoint : exécute ls -la dans le dépôt — tu dois voir .gitrust-ci.yml dans la liste. La taille du fichier doit être supérieure à 0 octet.

Étape 3 : Commite et pousse pour déclencher la CI¶

Ajoute le fichier et crée un commit :

git add .gitrust-ci.yml
git commit -m "ajoute configuration CI gitrust"
git push origin main

Sortie attendue :

[main a4f7b8c] ajoute configuration CI gitrust
 1 file changed, 10 insertions(+)
 create mode 100644 .gitrust-ci.yml
...
To git@gitrust.example.com:tonpseudo/mon-premier-depot.git
   3a8c21f..a4f7b8c  main -> main

Immédiatement après le push, dans ton navigateur, navigue vers /{owner}/{repo}/ci.

Sortie attendue : une entrée de pipeline apparaît avec le statut En attente ou En cours, associée au commit a4f7b8c et au message ajoute configuration CI gitrust.

Checkpoint : le pipeline apparaît dans la liste. S'il n'apparaît pas après 10 secondes, rafraîchis la page. S'il n'apparaît toujours pas, vérifie que la CI est bien activée (étape 1) et que le fichier .gitrust-ci.yml est bien à la racine du dépôt (pas dans un sous-dossier).

Étape 4 : Lis les logs du pipeline¶

Clique sur le pipeline dans la liste pour ouvrir la page de détail.

La page affiche :

• Le statut en cours (Pending → Running → Success ou Failure)
• Le commit et la branche associés
• Les logs en temps réel, mis à jour ligne par ligne

Attends la fin de l'exécution. Pour un projet minimal, cela prend 1 à 3 minutes selon la rapidité du serveur de build.

Sortie attendue pour un pipeline réussi (dernières lignes des logs) :

[build] cargo build: ok
[checks] cargo clippy: ok
[tests] cargo test: ok
Pipeline terminé avec succès.

Pour un pipeline en échec, les logs montrent la commande qui a échoué et le code de retour :

[tests] cargo test: FAILED (exit code 1)
error[E0277]: the trait bound `...` is not satisfied
Pipeline terminé en échec.

Checkpoint : le pipeline passe au statut Réussi (vert) ou Échoué (rouge). Dans les deux cas, tu as atteint l'objectif O3 — tu sais lire le résultat. Si le statut reste bloqué sur En cours plus de 10 minutes, consulte la section « Et si ça ne marche pas ».

Récapitulatif¶

• ✓ O1 accompli : tu as écrit un fichier .gitrust-ci.yml avec les sections language, build, checks et tests, adapté à ton langage
• ✓ O2 accompli : tu as déclenché le pipeline en poussant un commit — gitrust l'a automatiquement détecté et lancé l'exécution
• ✓ O3 accompli : tu as lu le statut et les logs sur /{owner}/{repo}/ci, identifiant si les étapes build/checks/tests ont réussi ou échoué

Et si ça ne marche pas¶

Prochaine étape¶

Tu as maintenant complété le parcours utilisateur de base : compte sécurisé → code versionné → collaboration en équipe → CI automatisée.

Pour aller plus loin :

• Comment gérer les clés SSH — plusieurs machines, rotation des clés
• Référence du schéma .gitrust-ci.yml — toutes les options disponibles
• Comprendre le cycle de vie d'une pull request — les états et transitions d'une PR