Zurück zum Blog
X24LABS

Erste Schritte mit Stitch Agent (v1)

Die originale v1-Einrichtungsanleitung: zwei CI-Jobs, ein Docker-Image und eine Handvoll Umgebungsvariablen. Zur historischen Referenz aufbewahrt.

Historischer Beitrag. Diese Anleitung beschreibt Stitch v1, das innerhalb deiner CI-Pipeline lief und über ein Docker-Image verteilt wurde. Wenn du Stitch heute installierst, folge stattdessen Erste Schritte mit Stitch 2.0. Die Jobs stitch-monitor und stitch-heal sowie das Image ghcr.io/x24labs/stitch werden nicht mehr gepflegt.

Stitch einzurichten dauert unter fünf Minuten. Du fügst zwei Jobs zu deiner CI-Konfiguration hinzu und Stitch übernimmt den Rest. Keine Server, keine API-Keys zu verwalten, kein Dashboard zu überwachen.

Voraussetzungen

GitLab CI Setup

Füge diese zwei Jobs zu deiner .gitlab-ci.yml hinzu:

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

Der stitch-monitor-Job aktiviert sich, wenn ein Upstream-Job fehlschlägt. Er liest die Logs und identifiziert den Fehler. Der stitch-heal-Job nimmt die Diagnose und erzeugt einen Fix.

Beide Jobs nutzen die .post-Stage und laufen daher nach allen regulären Pipeline-Stages. Sie triggern nur on_failure, kosten also null Compute-Zeit, wenn deine Pipeline besteht.

GitHub Actions Setup

Füge eine Workflow-Datei unter .github/workflows/stitch.yml hinzu:

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

Dieser Workflow startet, wenn dein CI-Workflow fehlschlägt. Er checkt den Code aus, führt den Monitor aus und wendet den Fix an.

Was als Nächstes passiert

Wenn deine Pipeline fehlschlägt:

  1. Stitch liest die Fehler-Logs
  2. Er identifiziert den Fehlertyp und die betroffenen Dateien
  3. Er erzeugt einen gezielten Patch
  4. Er validiert den Fix durch erneutes Ausführen der fehlgeschlagenen Checks
  5. Wenn der Fix besteht, pusht er einen Commit auf einen Fix-Branch und öffnet einen Merge Request

Du reviewst den MR wie jede andere Code-Änderung. Standardmäßig ist Auto-Merge aus. Du entscheidest, wann der Fix landet.

Konfiguration

Stitch funktioniert mit null Konfiguration. Für Teams, die mehr Kontrolle wollen, kannst du Optionen über Umgebungsvariablen setzen:

Das Setup verifizieren

Pushe einen Commit, der absichtlich eine Lint-Regel oder einen Test bricht. Beobachte, wie die Pipeline fehlschlägt und Stitch sie aufgreift. Innerhalb weniger Minuten solltest du einen neuen Branch und Merge Request sehen.

Wenn etwas nicht funktioniert, prüfe die Logs des Stitch-Jobs. Sie enthalten die vollständige Diagnose und alle Fehler, die beim Fix-Versuch auftraten.

Nächste Schritte

Zurück zum Blog