Wie man Apidog CLI API Tests in GitHub Actions ausführt (Vollständiger Workflow)

Ihre API-Tests bestehen auf Ihrem Computer. Dann führt ein Teamkollege eine Änderung zusammen, die den Login-Endpunkt unterbricht, und niemand bemerkt es, bis ein Kunde ein Ticket einreicht. Die Tests existierten. Sie wurden nur nie in dem Moment ausgeführt, in dem es darauf ankam: beim Pull Request, vor dem Merge.

Diese Lücke schließt die Continuous Integration. Sie verlagern die Tests von Ihrem lokalen Terminal in eine Pipeline, die sie automatisch bei jedem Push und jeder Änderung ausführt. Speziell für API-Tests ist der sauberste Weg hierfür ein Kommandozeilen-Runner, der genau die Szenarien ausführt, die Sie bereits erstellt haben, einen Pass/Fail-Exit-Code zurückgibt und CI entscheiden lässt, ob der Build grün oder rot wird.

TL;DR

• Die Apidog CLI ist ein npm-Paket, apidog-cli. Installieren Sie es in einem Workflow-Schritt mit npm install -g apidog-cli und führen Sie dann Szenarien mit apidog run aus.
• Sie führt die Testszenarien aus, die Sie in der Apidog-App über die ID entwerfen. Sie portieren Tests nicht in Code; die CLI führt dasselbe Szenario mithilfe eines Zugriffstokens zur Authentifizierung aus.
• Ein minimaler GitHub Actions-Job besteht aus vier Schritten: Checkout, Node einrichten, CLI installieren, apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t <scenarioId> -e <environmentId> -r junit,cli ausführen.
• Die CLI beendet sich mit einem Nicht-Null-Exit-Code, wenn eine Assertion fehlschlägt. GitHub liest diesen Exit-Code, lässt die Überprüfung fehlschlagen und blockiert den Merge. Das ist das gesamte Qualitäts-Gate; Sie konfigurieren nichts Zusätzliches.
• Speichern Sie das Zugriffstoken als GitHub Actions Secret und übergeben Sie es über env:. Committen Sie es niemals.
• Verwenden Sie -r junit, um Ergebnisse in ein Dashboard einzuspeisen, -r html für ein durchsuchbares Artefakt und if: always() im Upload-Schritt, damit Sie den Bericht auch bei fehlgeschlagenen Tests erhalten.

Warum API-Tests überhaupt in CI ausführen?

Ein Test, der nur ausgeführt wird, wenn Sie sich daran erinnern, ihn auszuführen, ist ein Test, dem Sie nicht vertrauen können. Lokale Ausführungen sind in Ordnung, während Sie das Szenario schreiben. Sie brechen zusammen, sobald ein Team beteiligt ist, da die Maschine jedes Entwicklers leicht unterschiedlich ist und niemand die gesamte Suite vor jedem Push ausführt.

CI löst das Vertrauensproblem, indem es die Ausführung automatisch und einheitlich macht. Jeder Pull Request löst denselben Job auf demselben sauberen Runner gegen dieselbe Umgebung aus. Wenn ein Endpunkt beginnt, eine 500 zurückzugeben oder ein Antwortschema abweicht, schlägt die Überprüfung auf dem PR fehl, der dies verursacht hat, mit dem Namen der Person, die es gepusht hat. Das Feedback kommt innerhalb von Minuten an, während die Änderung noch frisch ist, anstatt Tage später in der Produktion.

API-Tests passen hier gut, weil sie schnell und deterministisch sind. Ein Szenario trifft echte Endpunkte, prüft Statuscodes und Antwortkörper und besteht oder schlägt fehl. Es gibt keinen instabilen Browser, kein Rendering, auf das man warten muss. Das macht sie ideal als Merge-Gate: schnell genug, um bei jedem PR ausgeführt zu werden, und entscheidend genug, um einen schlechten zu blockieren. Wenn Sie einen breiteren Hintergrund dazu wünschen, was CI/CD ist und wie die Teile zusammenpassen, behandelt die Einführung zu was CI/CD ist und wie es funktioniert die Grundlagen.

Was die Apidog CLI tatsächlich macht

Hier ist der Teil, der Ihnen die meiste Zeit spart: Sie schreiben keinen Testcode für die CLI.

Sie erstellen Ihre Testszenarien visuell in der Apidog-App, mit den benötigten Anfragen, Assertions, Umgebungsvariablen und Daten. Die CLI ist ein Runner. Mit einer Szenario-ID und einem Zugriffstoken holt sie dieses Szenario aus Ihrem Apidog-Projekt und führt es Anfrage für Anfrage aus, wobei jede Assertion genau wie in der App ausgewertet wird. Das Ergebnis ist ein Bericht und ein Exit-Code.

Dieses Design ist wichtig für CI. Die meisten Test-Runner verlangen, dass Sie eine separate Codedarstellung Ihrer Tests pflegen; das, was Sie in der Pipeline ausführen, weicht von dem ab, was Sie entworfen haben. Mit Apidog führt die Pipeline dasselbe Szenario aus, das Ihr Team bereits in der App pflegt. Aktualisieren Sie eine Assertion im visuellen Editor und der nächste CI-Lauf übernimmt sie. Es gibt keine zweite Kopie, die synchron gehalten werden muss.

Das Binary ist apidog, verteilt als npm-Paket apidog-cli. Jeder Befehl beginnt mit apidog run. Wenn Sie sehen möchten, wie der Runner in einen umfassenderen Automatisierungs-Workflow integriert ist, behandelt die Anleitung zur Integration der Apidog CLI mit Claude Skills für die API-Testautomatisierung diesen Aspekt; dieser Artikel konzentriert sich auf die Flags, die Sie für eine GitHub Actions-Pipeline benötigen.

Bevor Sie beginnen: drei Dinge, die Sie benötigen

Sie benötigen drei Informationen, bevor der Workflow ausgeführt wird. Zwei sind IDs aus Ihrem Apidog-Projekt; eine ist ein Token.

1. Ein Testszenario. Erstellen Sie es in der Apidog-App, falls noch nicht geschehen. Dies ist das, was die CLI ausführt. Ein einzelnes Anmelde- und Profilabruf-Szenario reicht für den Anfang aus; Sie können später skalieren.
2. Die Szenario-ID und die Umgebungs-ID. Die Szenario-ID teilt der CLI mit, was ausgeführt werden soll; die Umgebungs-ID teilt ihr mit, wo (Entwicklung, Staging, Produktion). Beide sind in der App sichtbar.
3. Ein Zugriffstoken. Dieses authentifiziert die CLI bei Ihrem Apidog-Konto, damit es das Szenario abrufen und ausführen kann.

Der sauberste Weg, all dies auf einmal zu erhalten, ist der CI/CD-Tab des Szenarios. Öffnen Sie das Testszenario, das Sie automatisieren möchten, wechseln Sie zum CI/CD-Tab und wählen Sie die Befehlszeilenoption. Klicken Sie, um ein Zugriffstoken hinzuzufügen und eines zu generieren. Apidog stellt den vollständigen apidog run-Befehl für Sie zusammen, wobei das Zugriffstoken, die Szenario-ID (-t) und die Umgebungs-ID (-e) bereits ausgefüllt sind. Kopieren Sie diesen Befehl; er ist die Basis für Ihren CI-Schritt.

Eine Regel, die man vorab festhalten sollte: Behandeln Sie das Zugriffstoken wie ein Passwort. Fügen Sie es nicht in eine committete Workflow-Datei ein. Speichern Sie es als GitHub Actions Secret und referenzieren Sie es als Umgebungsvariable. Jedes Beispiel unten verwendet $APIDOG_ACCESS_TOKEN genau aus diesem Grund.

Schritt 1: Das Zugriffstoken als GitHub Secret speichern

Öffnen Sie Ihr Repository auf GitHub. Gehen Sie zu Einstellungen (Settings), dann zu Secrets und Variablen (Secrets and variables), dann zu Actions und klicken Sie auf Neues Repository-Secret (New repository secret).

• Name: APIDOG_ACCESS_TOKEN
• Secret: fügen Sie das von Apidog für Sie generierte Token ein

Speichern Sie es. Das Token ist nun im Ruhezustand verschlüsselt und nur Workflow-Läufen zugänglich, niemals in Protokollen gedruckt. Im Workflow werden Sie es als ${{ secrets.APIDOG_ACCESS_TOKEN }} referenzieren und über einen env:-Block an die CLI übergeben. Die Szenario-ID und die Umgebungs-ID sind nicht geheim; es sind harmlose IDs, sodass Sie sie direkt in die Workflow-Datei schreiben können. Nur das Token muss geschützt werden.

Wenn Ihr Team über mehrere Repositories hinweg arbeitet, die alle dasselbe Apidog-Projekt verwenden, definieren Sie das Secret stattdessen einmal auf Organisationsebene und gewähren Sie den relevanten Repositories Zugriff. Derselbe Name, ein Ort zum Rotieren.

Schritt 2: Der minimale Workflow

Erstellen Sie .github/workflows/api-tests.yml in Ihrem Repository. Dies ist der kleinste Workflow, der etwas Nützliches tut: Er führt Ihr Szenario bei jedem Pull Request aus, der auf main abzielt.

name: API tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run API test scenario
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Ersetzen Sie 605067 durch Ihre Szenario-ID und 1629989 durch Ihre Umgebungs-ID. Committen Sie diese Datei, öffnen Sie einen Pull Request und beobachten Sie den Tab "Checks". Der Job startet einen Ubuntu-Runner, installiert Node 20, installiert die CLI und führt Ihr Szenario aus. Wenn jede Assertion bestanden wird, wird der Check grün. Wenn eine fehlschlägt, beendet sich apidog run mit einem Exit-Code ungleich Null, GitHub lässt den Check fehlschlagen und der PR zeigt ein rotes X.

Dieses rote X ist der ganze Punkt. Niemand muss ein Protokoll lesen, um zu wissen, dass etwas kaputt ist; der fehlgeschlagene Check ist direkt im Pull Request sichtbar.

Ein Hinweis zum Installationsschritt: Das globale npm install -g apidog-cli ist einfach und funktioniert. Wenn Sie die globalen Pakete des Runners nicht verändern möchten, können Sie den Installationsschritt überspringen und die CLI stattdessen über npx aufrufen:

      - name: Run API test scenario
        run: npx apidog-cli run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -e 1629989 -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Beide Ansätze führen dasselbe Szenario aus. npx ist sauberer bei kurzlebigen Runnern; die globale Installation ist marginal schneller, wenn Sie node_modules zwischen den Läufen cachen. Wählen Sie, was zu Ihrem Stil passt.

Schritt 3: Einen Bericht veröffentlichen, den Sie tatsächlich lesen können

Ein grüner oder roter Check zeigt Ihnen das Ergebnis an. Wenn ein Test fehlschlägt, möchten Sie wissen, warum, und dafür benötigen Sie den Bericht.

Das Flag -r (oder --reporters) steuert die Berichtsformate. Es akzeptiert cli, html, json und junit, durch Kommas getrennt. Für CI haben sich zwei Formate bewährt:

• junit gibt XML im Standard-JUnit-Format aus. Fast jedes CI-Dashboard und Testberichterstattungstool weiß, wie man es in einen Bestanden/Fehlgeschlagen-Baum parst.
• html erstellt einen eigenständigen Bericht, den Sie als Build-Artefakt speichern und in einem Browser öffnen können, mit der vollständigen Anfrage und Antwort für jeden Schritt.

Behalten Sie cli ebenfalls bei, wenn Sie lesbare Ausgabe im Build-Protokoll selbst wünschen. Hier ist der Ausführungsschritt, der aktualisiert wurde, um beide Berichtsformate zu erstellen und in ein Verzeichnis zu schreiben, plus einem Upload-Schritt, damit der Bericht den Lauf überlebt:

      - name: Run API test scenario
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -n 1 \
            -r html,junit,cli \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload test report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-report
          path: ./apidog-reports

Zwei Details sorgen dafür, dass dies so funktioniert, wie Sie es möchten. Das Flag --out-dir weist die CLI an, wohin die Berichte geschrieben werden sollen; hier ist es ./apidog-reports, das der Upload-Schritt dann abruft. Und if: always() im Upload-Schritt ist das Wichtige: Standardmäßig überspringt GitHub spätere Schritte, sobald ein Schritt fehlschlägt, aber Sie benötigen den Bericht am dringendsten, wenn die Tests fehlgeschlagen sind. if: always() erzwingt die Ausführung des Uploads, unabhängig vom Testergebnis. Nach Abschluss des Jobs erscheint der Bericht unter "Artifacts" auf der Übersichtsseite des Laufs, bereit zum Download.

Das Flag -n 1 setzt die Iterationsanzahl auf einen Lauf; erhöhen Sie es, wenn Sie das Szenario mehrmals hintereinander ausführen möchten.

Wenn Sie möchten, dass GitHub die JUnit-Ergebnisse inline als annotierten Check anzeigt und nicht als herunterladbare Datei, fügen Sie nach dem Ausführungsschritt eine `published-test-results`-Aktion hinzu und verweisen Sie diese auf ./apidog-reports/*.xml. Dies wandelt das XML in eine Bestanden/Fehlgeschlagen-Zusammenfassung um, die an den Lauf angehängt ist, was für größere Suiten praktisch ist, bei denen das Scrollen des Protokolls unpraktisch ist.

Schritt 4: Die richtige Umgebung zur richtigen Zeit testen

Ein Pull Request sollte gegen Staging testen. Eine Bereitstellung in der Produktion sollte gegen die Produktion verifiziert werden. Dasselbe Szenario kann beides; Sie ändern einfach die Umgebungs-ID mit -e.

Ein gängiges, robustes Setup verwendet zwei Trigger in einer Workflow-Datei. Pull Requests führen das Szenario als Merge-Gate gegen Ihre Staging-Umgebung aus. Pushes an main (was ein Merge erzeugt) führen dasselbe Szenario als Smoke-Test nach der Bereitstellung gegen die Produktion aus.

name: API tests

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  pr-check:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Test staging
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r junit,cli \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: staging-report
          path: ./apidog-reports

  prod-smoke:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Smoke test production
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1730055 \
            -r cli \
            --on-error end
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Die beiden Umgebungs-IDs (1629989 für Staging, 1730055 für Produktion) sind der einzige wesentliche Unterschied. Der PR-Job erstellt und archiviert einen JUnit-Bericht, damit Reviewer Fehler untersuchen können; der Produktions-Smoke-Test läuft schlank und schlägt schnell fehl mit --on-error end, was bei der ersten fehlgeschlagenen Assertion stoppt, sodass Sie schnell erfahren, dass eine Bereitstellung schiefgelaufen ist.

--on-error ist wissenswert. Es steuert, was passiert, wenn ein Schritt mitten im Szenario fehlschlägt. end stoppt den Lauf beim ersten Fehler (schnelles Feedback, gut für Smoke-Tests). continue führt jeden verbleibenden Schritt aus, sodass Sie alle Fehler in einem Bericht sehen (gut für eine gründliche PR-Prüfung). ignore überspringt einen bekanntermaßen instabilen Schritt, ohne den Lauf zu entgleisen. Was auch immer Sie wählen, der Lauf endet immer noch mit einem Nicht-Null-Exit-Code, wenn etwas fehlgeschlagen ist, sodass das Gate in jedem Fall hält.

Weiterführend: Matrix-Läufe, Ordner und datengesteuerte Tests

Sobald das grundlegende Gate eingerichtet ist, erweitern einige Flags es ohne viel zusätzliches YAML.

Führen Sie einen gesamten Funktionsbereich aus, nicht nur ein Szenario. Ersetzen Sie -t <scenarioId> durch -f <folderId>, um jedes Szenario innerhalb eines Ordners auszuführen, oder --test-suite <testSuiteId>, um eine kuratierte Suite auszuführen. Suiten sind das richtige Werkzeug, wenn Sie eine spezifische, geordnete Reihe von Szenarien zusammen als einen logischen Job ausführen möchten; die Anleitung zum Skalieren automatisierter API-Tests mit Testsuiten behandelt, wann man sie verwenden sollte.

Testen Sie mehrere Umgebungen parallel. Eine Matrix führt denselben Job über mehrere Umgebungs-IDs gleichzeitig aus:

jobs:
  api-tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        env-id: [1629989, 1730055]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Run scenario against ${{ matrix.env-id }}
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e ${{ matrix.env-id }} \
            -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

GitHub startet einen Runner pro Matrixwert, sodass Staging und Produktion gleichzeitig getestet werden und jeder sein eigenes Bestanden/Fehlgeschlagen meldet.

Steuern Sie Iterationen aus einer Datendatei. Das Flag -d führt ein Szenario über Zeilen einer CSV- oder JSON-Datei aus, wobei jede Zeile als separater Durchlauf behandelt wird: apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -d ./test-data.csv -r junit. So validieren Sie denselben Endpunkt gegen fünfzig Eingaben, ohne fünfzig Szenarien zu erstellen.

Gegen einen Branch ausführen. Wenn Ihr Team die Branch-Funktion von Apidog verwendet, verweist --branch <branchName> den Lauf auf einen bestimmten Branch anstelle von main, wodurch der PR eines Feature-Branches gegen die Szenariodefinitionen dieses Branches getestet werden kann.

Fehlerbehebung bei häufigen CI-Fehlern

Der Job ist grün, aber ein Test hätte fehlschlagen müssen. Überprüfen Sie, ob der Exit-Code des apidog run-Schritts tatsächlich GitHub erreicht. Wenn Sie den Befehl in eine Shell-Pipeline verpackt oder || true angehängt haben, wird der Nicht-Null-Exit-Code verschluckt und das Gate funktioniert stillschweigend nicht mehr. Entfernen Sie alles, was den Exit-Code maskiert. Führen Sie den Befehl in einer eigenen Zeile oder als letzten Befehl in einem run:-Block aus, damit sein Exit-Status der Exit-Status des Schritts ist.

Authentifizierung schlägt fehl. Die häufigste Ursache ist eine Nichtübereinstimmung des Secret-Namens. Der env:-Schlüssel, die Wertreferenz ${{ secrets.APIDOG_ACCESS_TOKEN }} und das Secret, das Sie in den Einstellungen erstellt haben, müssen alle denselben Namen verwenden. Bestätigen Sie auch, dass das Token in Apidog seit dem Speichern nicht neu generiert wurde; eine Neugenerierung macht das alte Token ungültig.

Lokal erfolgreich, in CI fehlgeschlagen. Fügen Sie dem Ausführungsbefehl temporär --verbose hinzu. Es werden die vollständige Anfrage des Runners und die vollständige zurückerhaltene Antwort ausgegeben, was normalerweise den Unterschied aufzeigt, oft eine Umgebungsvariable, die auf Ihrem Rechner, aber nicht in der CI-Umgebung gesetzt ist, oder ein Staging-Dienst, der sich anders verhält als Ihr lokaler.

Berichte werden nicht als Artefakte angezeigt. Stellen Sie sicher, dass --out-dir im Ausführungsschritt und path: im Upload-Schritt auf dasselbe Verzeichnis zeigen und dass der Upload-Schritt if: always() enthält. Ohne if: always() überspringt ein fehlgeschlagener Test den Upload, und Sie verlieren den Bericht genau dann, wenn Sie ihn benötigen.

Der Runner kann Ihre API nicht erreichen. Wenn Ihre Staging- oder Produktionsumgebung hinter einer Firewall oder einem VPN liegt, kann ein öffentlicher, von GitHub gehosteter Runner sie nicht erreichen. Sie benötigen einen selbst gehosteten Runner in Ihrem Netzwerk oder einen Allowlist-Eintrag für die IP-Bereiche von GitHub.

Wie sich dies im Vergleich zu Alternativen verhält

Sie könnten API-Tests als Code mit einem Framework schreiben, sie in einen Test-Runner integrieren und diesen von Actions aufrufen. Das funktioniert, aber Sie pflegen nun eine Code-Suite, die mit der API und dem, was Ihr Team in seinem API-Tool entwirft, synchron bleiben muss. Der Apidog-Ansatz überspringt diese Duplizierung: Das Szenario, das Ihr Team bereits in der App pflegt, ist der Test, der in CI ausgeführt wird.

Sie könnten auch rohe curl-Aufrufe in einem Workflow-Schritt skripten. Gut für einen einzelnen Health Check, danach schmerzhaft, weil Sie Assertions, Umgebungswechsel und Berichterstattung manuell erstellen, die die CLI Ihnen kostenlos bietet.

GitHub Actions ist auch nicht die einzige Heimat dafür. Derselbe apidog run-Befehl kann in GitLab CI, Jenkins, CircleCI oder jeden anderen Runner eingefügt werden, der einen Shell-Befehl ausführen und einen Exit-Code lesen kann. Wenn GitHub Actions nicht Ihre Plattform ist, übertragen sich die hier gezeigten Muster direkt; siehe den Leitfaden zur Automatisierung von API-Tests in CI/CD für die plattformübergreifende Ansicht oder die Anleitung zur Integration von Apidog-automatisierten Tests mit Jenkins, wenn Sie Jenkins verwenden.

Um die Szenarien zu erstellen, die Sie ausführen werden, laden Sie Apidog herunter, entwerfen Sie Ihre Tests in der App und kopieren Sie den CLI-Befehl aus dem CI/CD-Tab des Szenarios. Der Runner ist ein kostenloses npm-Paket; was Sie ausführen können, hängt von Ihrem Apidog-Projekt ab, aber der Kommandozeilen-Runner selbst ist kein separates kostenpflichtiges Produkt.

Zusammenfassung

Das Setup ist kleiner, als es aussieht. Erstellen Sie ein Szenario in Apidog, speichern Sie ein Zugriffstoken als GitHub Secret und fügen Sie eine Handvoll Schritte zu einer Workflow-Datei hinzu. Von dort aus führt jeder Pull Request Ihre API-Tests automatisch aus, ein fehlerhafter Endpunkt färbt den Check vor dem Merge rot, und der Bericht wartet im Tab "Artefakte", wann immer Sie sehen müssen, was kaputt gegangen ist.

Der Grund, warum es einfach bleibt, ist die Arbeitsteilung. Die Apidog-App ist für die Tests zuständig; die CLI führt sie aus; GitHub liest den Exit-Code. Nichts muss dupliziert oder synchron gehalten werden. Wenn Sie eine Assertion in der App aktualisieren, verwendet der nächste CI-Lauf diese. Das macht es wert, dies am ersten Tag eines Projekts zu tun, anstatt es nach dem ersten Produktionsvorfall anzubringen.