Dépanner la CI intégrée (Dagger)

À qui s'adresse cette page

Administrateurs confrontés à des pipelines bloqués, des workers CI qui ne répondent plus, ou des erreurs SBOM/Dependency-Track.

Architecture CI de gitrust

flowchart LR
    A[git push] --> B[gitrust-hooks
on_push]
    B --> C[CiWorker async
gitrust-core]
    C --> D{CI_REMOTE_HOST}
    D -->|localhost| E[Dagger Engine
local]
    D -->|runner distant| F[Runner SSH
CI_REMOTE_HOST]
    E --> G[Pipeline exécuté]
    F --> G
    G --> H[Logs stockés
CI_WORKSPACE_PATH]
    G --> I[Status → DB]
    G -->|CI_SBOM_ENABLED=true| J[Syft → SBOM]
    J -->|CI_DTRACK_ENABLED=true| K[Dependency-Track]

Vérifier l'état de la CI

Pipeline bloqué à l'état pending

Un pipeline reste en pending si le worker ne le prend pas en charge.

# Vérifier les logs du worker CI
sudo journalctl -u gitrust -n 100 --no-pager | grep -i "ci\|pipeline\|worker\|dagger"

# Vérifier que CI_ENABLED est bien à true
grep CI_ENABLED /opt/gitrust/.env

Si CI_ENABLED=false, aucun pipeline ne s'exécute. Pour désactiver temporairement la CI sans arrêter gitrust :

# Désactiver la CI (les pipelines s'accumulent en pending mais ne s'exécutent pas)
sed -i 's/^CI_ENABLED=.*/CI_ENABLED=false/' /opt/gitrust/.env
sudo systemctl restart gitrust

Nombre maximum de pipelines concurrentes atteint

grep CI_MAX_CONCURRENT /opt/gitrust/.env
# Défaut : 4 — augmenter si la machine a les ressources

Les pipelines supplémentaires attendent en file. Vérifiez qu'aucun pipeline n'est bloqué indéfiniment (timeout CI_DEFAULT_TIMEOUT, défaut : 3600 s).

Erreur : dagger: command not found

Le binaire dagger n'est pas dans le PATH de l'utilisateur gitrust.

# Vérifier depuis l'utilisateur gitrust
sudo -u gitrust which dagger
sudo -u gitrust dagger version

Installation de Dagger :

curl -fsSL https://dl.dagger.io/dagger/install.sh | sudo sh
# Le binaire est installé dans /usr/local/bin/dagger

Si Dagger est installé dans un chemin non standard, précisez-le dans .env :

CI_DAGGER_BIN=/usr/local/bin/dagger

Erreur : connexion au runner distant échoue

Si CI_REMOTE_HOST pointe vers une machine distante :

# Tester la connexion SSH depuis l'utilisateur gitrust
sudo -u gitrust ssh -i /opt/gitrust/data/ci_runner_key \
  -p ${CI_REMOTE_SSH_PORT:-22} \
  ${CI_REMOTE_USER:-$USER}@${CI_REMOTE_HOST} \
  "dagger version"

Causes courantes :

Symptôme Cause Correction
Permission denied (publickey) Clé CI runner non autorisée sur le runner Ajouter la clé publique dans ~/.ssh/authorized_keys du runner
Connection refused Le runner est éteint ou le port SSH est fermé Vérifier l'état du runner et le firewall
dagger: command not found sur le runner Dagger non installé sur la machine distante Installer Dagger sur le runner
Timeout rsync CI_REMOTE_PATH inexistant sur le runner ssh runner "mkdir -p /opt/gitrust-ci"

Erreur SBOM : syft: command not found

# Vérifier depuis l'utilisateur gitrust
sudo -u gitrust which syft

# Installer Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sudo sh -s -- -b /usr/local/bin

# Ou préciser le chemin dans .env
CI_SYFT_BIN=/usr/local/bin/syft

Si vous ne souhaitez pas utiliser SBOM :

CI_SBOM_ENABLED=false
CI_DTRACK_ENABLED=false

Erreur Dependency-Track : push SBOM échoue

# Vérifier la connectivité vers Dependency-Track
curl -s -H "X-Api-Key: ${CI_DTRACK_API_KEY}" \
  "${CI_DTRACK_URL}/v1/project" | head -100

# Attendu : liste JSON des projets
# Erreur 401 : clé API invalide ou expirée
# Connection refused : CI_DTRACK_URL incorrect ou Dtrack non démarré

Vérifiez dans les logs gitrust :

sudo journalctl -u gitrust --since "1 hour ago" --no-pager \
  | grep -i "dtrack\|sbom\|dependency"

Timeout de pipeline

Si un pipeline dépasse CI_DEFAULT_TIMEOUT (défaut : 3600 s = 1 h), il est annulé avec le statut timeout.

Pour les projets avec des builds très longs (compilation Rust complète, etc.) :

# Augmenter le timeout global
CI_DEFAULT_TIMEOUT=7200   # 2 heures

# Ou surcharger par pipeline dans .gitrust-ci.yml :
# pipeline:
#   timeout: 7200

Nettoyer l'espace disque CI

Les artefacts et workspaces CI s'accumulent dans CI_WORKSPACE_PATH (défaut : /tmp/gitrust-ci) et les logs dans la base de données.

# Espace occupé par les workspaces CI
du -sh /tmp/gitrust-ci/

# Nettoyer manuellement (uniquement si aucun pipeline en cours)
sudo systemctl stop gitrust
sudo rm -rf /tmp/gitrust-ci/*
sudo systemctl start gitrust

Les logs en base sont purgés automatiquement selon CI_LOG_RETENTION_DAYS (défaut : 30 jours).

Désactiver la CI temporairement

Pour désactiver toute exécution CI sans arrêter gitrust (utile lors d'une maintenance) :

# Dans .env
CI_ENABLED=false
sudo systemctl restart gitrust

Les pipelines déclenchés pendant cette période restent en pending et peuvent être relancés une fois la CI réactivée.

Pour aller plus loin