Retour au blog
X24LABS

Démarrer avec Stitch Agent (v1)

Le guide d'installation v1 original : deux jobs CI, une image Docker et quelques variables d'environnement. Conservé à titre historique.

Article historique. Ce guide décrit Stitch v1, qui tournait dans votre pipeline CI et était distribué via une image Docker. Si vous installez Stitch aujourd’hui, suivez plutôt Démarrer avec Stitch 2.0. Les jobs stitch-monitor / stitch-heal et l’image ghcr.io/x24labs/stitch ne sont plus maintenus.

Installer Stitch prend moins de cinq minutes. Vous ajoutez deux jobs à votre configuration CI et Stitch s’occupe du reste. Aucun serveur, aucune clé API à gérer, aucun dashboard à surveiller.

Prérequis

Installation GitLab CI

Ajoutez ces deux jobs à votre .gitlab-ci.yml :

stitch-monitor:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch monitor
  when: on_failure

stitch-heal:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch heal
  needs: ["stitch-monitor"]
  when: on_failure

Le job stitch-monitor s’active quand un job en amont échoue. Il lit les logs et identifie l’échec. Le job stitch-heal prend le diagnostic et génère un correctif.

Les deux jobs utilisent le stage .post, donc ils s’exécutent après toutes vos étapes de pipeline habituelles. Ils ne se déclenchent que on_failure, donc ils coûtent zéro temps de calcul quand votre pipeline passe.

Installation GitHub Actions

Ajoutez un fichier workflow à .github/workflows/stitch.yml :

name: Stitch
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  heal:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/x24labs/stitch:latest
    steps:
      - uses: actions/checkout@v4
      - run: stitch monitor && stitch heal

Ce workflow se déclenche quand votre workflow CI échoue. Il fait un checkout du code, lance le monitor et applique le correctif.

Ce qui se passe ensuite

Quand votre pipeline échoue :

  1. Stitch lit les logs d’échec
  2. Il identifie le type d’erreur et les fichiers concernés
  3. Il génère un patch ciblé
  4. Il valide le correctif en relançant les vérifications qui ont échoué
  5. Si le correctif passe, il pousse un commit sur une branche de fix et ouvre une merge request

Vous relisez la MR comme n’importe quel changement de code. Par défaut, l’auto-merge est désactivé. Vous décidez quand le correctif atterrit.

Configuration

Stitch fonctionne avec zéro configuration. Pour les équipes qui veulent plus de contrôle, vous pouvez définir des options via des variables d’environnement :

Vérifier l’installation

Poussez un commit qui casse volontairement une règle de lint ou un test. Regardez le pipeline échouer, puis regardez Stitch le récupérer. Vous devriez voir une nouvelle branche et une merge request en quelques minutes.

Si quelque chose ne fonctionne pas, regardez les logs du job Stitch. Ils contiennent le diagnostic complet et toute erreur rencontrée pendant la tentative de correction.

Étapes suivantes

Retour au blog