Build- und Test-Status auf der Karte anzeigen

Wenn der Build rot ist, will das Team es auf der Karte sehen und nicht in einem zweiten Tab. Diese Anleitung meldet den Build- und Teststatus aus deiner Pipeline an Zuuna. Sie gehört zum Developer-Plan und funktioniert mit jedem CI-System, das einen HTTP-Aufruf absetzen kann.

Was du brauchst

• Den Developer-Plan — siehe Preise.
• Ein API-Token mit dem Scope git:write, hinterlegt als Secret in deiner CI.
• Idealerweise schon eingerichtet: Commits mit Karten verknüpfen — dann findet Zuuna die Karte von allein.

1. Token mit git:write bereitlegen

Erstelle in der Developer-Konsole ein Token mit ausschließlich git:write und leg es als Secret in deiner CI ab — bei GitHub Actions unter Settings → Secrets and variables → Actions. Ein CI-Runner braucht nicht mehr als diesen einen Scope.

2. Den Status aus der Pipeline melden

Ein Aufruf am Ende des Jobs genügt. Als GitHub-Actions-Schritt:

- name: Build-Status an Zuuna melden
  if: always()
  run: |
    curl -sS -X POST https://app.zuuna.de/api/v1/git/checks \
      -H "Authorization: Bearer $ZUUNA_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "repo": { "remoteUrl": "'"$GITHUB_SERVER_URL/$GITHUB_REPOSITORY"'" },
        "checks": [{
          "name": "build",
          "status": "'"${{ job.status == 'success' && 'passing' || 'failing' }}"'",
          "sha": "'"$GITHUB_SHA"'",
          "branch": "'"${GITHUB_REF#refs/heads/}"'",
          "url": "'"$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID"'"
        }]
      }'
  env:
    ZUUNA_TOKEN: ${{ secrets.ZUUNA_TOKEN }}

if: always() ist der wichtige Teil — ohne ihn meldet die Pipeline nur die grünen Läufe, und genau die interessieren niemanden.

Erlaubte Werte für status: passing, failing, pending. Bis zu 1.000 Prüfergebnisse passen in einen Aufruf, wenn du mehrere Jobs auf einmal meldest.

3. Verstehen, wie Zuuna die Karte findet

Zuuna sucht die Karte in dieser Reihenfolge: über den Commit-SHA, den Branch oder den Pull Request, sofern dort bereits eine Verknüpfung besteht. Findet sich nichts, greift ein Kartenschlüssel im Branch-Namen. Deshalb lohnt sich der post-commit-Hook aus dem ersten Tutorial: Er stellt die Verknüpfung her, an der sich später alles andere orientiert.

4. Die Karte prüfen

Auf der Karte steht der Check mit Namen, Status und einem Link zum Log — ein Klick, und du bist im richtigen Lauf. In der Aktivität der Karte taucht der Statuswechsel ebenfalls auf.

5. Re-Runs sauber halten

Startest du denselben Job neu, überschreibt das Ergebnis mit demselben Namen das alte, statt eine zweite Zeile anzulegen. Auf der Karte steht damit immer der aktuelle Stand und keine Historie aus zwölf Versuchen. Wenn du mehrere Prüfungen getrennt sehen willst, gib ihnen unterschiedliche Namen — build, tests, lint.

Wenn es nicht klappt

• Kein Check auf der Karte. Meist findet Zuuna keine Karte: weder eine bestehende Verknüpfung noch ein Kartenschlüssel im Branch-Namen. Prüf beides.
• 401 oder 403. Token fehlt, ist widerrufen oder hat git:write nicht.
• Nur grüne Läufe kommen an. if: always() fehlt — der Schritt wird bei einem fehlgeschlagenen Job übersprungen.
• Der rote Build löst keine Automatisierung aus. Prüf, ob eine Regel auf „CI rot“ hört. Und beachte: pending löst grundsätzlich nichts aus.

Nächste Schritte

• Karten automatisch durch Git bewegen — auf einen roten Build reagieren.
• Der Code-Graph — was ohne Ticket live ging.
• API-Token erstellen und die erste Abfrage schicken.