Wie man API-Tests mit Apidog CLI ausführt?

Ihre API-Tests laufen auf Ihrem Laptop. Dann führt jemand um 2 Uhr morgens eine Änderung zusammen, der Staging-Endpunkt liefert eine fehlerhafte Nutzlast, und niemand bemerkt es, bis ein Kunde am nächsten Morgen ein Ticket einreicht. Die Tests existierten. Sie liefen nur nie dort, wo es wichtig war: innerhalb der Pipeline, bei jedem Push, ohne dass ein Mensch einen Knopf klicken musste.

Diese Lücke zwischen „existierenden Tests“ und „automatisch laufenden Tests“ schließt genau ein Kommandozeilen-Runner. Die Apidog CLI nimmt die Testszenarien, die Sie bereits in der Apidog Desktop- oder Web-App erstellt haben, und führt sie kopflos von einem Terminal aus. Keine GUI, kein manuelles Klicken. Sie installieren es mit einem npm-Befehl, verweisen es auf ein Testszenario, und es beendet sich mit einem sauberen Statuscode und einem Bericht, den Sie in jedem CI-System veröffentlichen können. Das macht es zur Brücke zwischen dem visuellen Test-Builder und Ihrer CI/CD-Plattform.

TL;DR

• Die Apidog CLI ist ein npm-Paket namens apidog-cli. Installieren Sie es global mit npm install -g apidog-cli und führen Sie dann Szenarien mit dem Befehl apidog run aus.
• Sie führt die Testszenarien aus, die Sie in Apidog entwerfen. Sie müssen Tests nicht als Code neu schreiben; die CLI führt dasselbe Szenario anhand der ID aus, wobei ein Zugriffstoken zur Authentifizierung verwendet wird.
• Grundausführung: apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenarioId> -e <environmentId> -n 1 -r html,cli.
• Reporter decken cli, html, json und junit ab. JUnit XML ist das, was direkt in CI-Test-Dashboards integriert wird.
• Ein Exit-Code ungleich Null bei Testfehlern macht die CLI zu einem echten Qualitäts-Gate. Fehlerhafte Tests lassen den Build standardmäßig fehlschlagen.
• Es funktioniert in jedem CI-Runner, der Node.js hat: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines und mehr.

Was die Apidog CLI tatsächlich ist

Apidog ist eine All-in-One-API-Plattform: Sie entwerfen das Schema, debuggen Anfragen, erstellen automatisierte Testszenarien, mocken Endpunkte und veröffentlichen Dokumentationen in einem einzigen Arbeitsbereich. Der größte Teil dieser Arbeit erfolgt in einer visuellen Oberfläche. Sie verketten Anfragen zu einem Testszenario, fügen Zusicherungen hinzu, ziehen Werte aus einer Antwort in die nächste und durchlaufen eine Datendatei.

Die CLI ist der kopflose Ausführer für diese Szenarien. Sie hat kein eigenes Testformat. Sie greift in Ihr Apidog-Projekt, findet das Szenario, das Sie anhand der ID benannt haben, und führt es genau so aus, wie es die App tun würde, und meldet dann das Ergebnis zurück. Stellen Sie sich dies als die Beziehung zwischen einem Build-Tool und Ihrem Quellcode vor: die Quelle der Wahrheit lebt im Projekt, und die CLI ist das Ding, das es ohne anwesende Person ausführt.

Dies ist wichtig, da es den häufigsten Grund beseitigt, warum API-Tests verrotten. Wenn Tests nur als anklickbare Schritte in einer Desktop-App existieren, werden sie ausgeführt, wenn sich jemand daran erinnert. Wenn sie von einem einzeiligen Befehl ausgeführt werden, können Sie sie in eine Pipeline einbinden und sie laufen bei jedem Commit, jeder Zusammenführung, jedem nächtlichen Zeitplan. Der visuelle Builder ermöglicht Ihnen eine schnelle Erstellung; die CLI bietet Ihnen Automatisierung. Sie erhalten beides, ohne sich entscheiden zu müssen.

Wenn Sie aus der Postman-Welt kommen, ist das mentale Modell klar. Die Apidog CLI übernimmt die Rolle, die die Postman CLI oder Newman für Postman-Sammlungen spielt, außer dass sie Apidog-Testszenarien ausführt und als einzelnes Paket ausgeliefert wird. Wir haben diesen Vergleich ausführlich in Postman CLI vs. Newman und die umfassendere Frage des Ausführens von Sammlungen in CI ohne Newman behandelt, falls Sie migrieren.

Voraussetzungen

Bevor Sie einen einzigen Befehl ausführen, benötigen Sie drei Dinge:

1. Node.js v16 oder höher. Die CLI wird als npm-Paket ausgeliefert, daher ist eine Node-Runtime die einzige Systemabhängigkeit. Überprüfen Sie Ihre Version mit node -v. Jedes CI-Image mit Node 16+ erfüllt bereits die Anforderungen.
2. Ein Apidog-Testszenario. Die CLI führt Szenarien aus, nicht lose Anfragen. Erstellen Sie zuerst eines in der Apidog-App: verketten Sie Ihre Anfragen, fügen Sie Zusicherungen hinzu, richten Sie alle datengesteuerten Iterationen ein, die Sie benötigen. Wenn Sie neu in der Erstellung von Zusicherungen sind, führt Sie API-Assertions: ein praktischer Leitfaden durch die Validierung von Antworten.
3. Ein Zugriffstoken. Dies authentifiziert die CLI bei Ihrem Apidog-Konto, damit sie das Szenario abrufen und ausführen kann. Sie generieren es im CI/CD-Tab des Testszenarios; mehr dazu weiter unten.

Das ist alles. Keine separate Apidog-Installation auf der CI-Box, keine GUI, keine Lizenzdatei. Das Paket und ein Token reichen aus.

Installation der Apidog CLI

Installieren Sie es global mit npm:

npm install -g apidog-cli

Bestätigen Sie dann, dass alles korrekt aufgelöst wurde:

node -v && apidog -v && which node && which npm && which apidog

Wenn das Versionsnummern und Pfade ausgibt, sind Sie fertig. Das Binary ist apidog, daher beginnt jeder Befehl mit apidog run.

Auf einem Entwicklerrechner ist eine globale Installation in Ordnung. In CI gibt es zwei sinnvolle Muster. Das erste ist die Neuinstallation bei jedem Pipeline-Durchlauf, was garantiert, dass Sie die neueste Version verwenden:

npm install -g apidog-cli
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

Das zweite ist die Ausführung ohne permanente globale Installation über npx, wodurch die globalen Pakete des Runners nicht verändert werden:

npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

Beide funktionieren. Der npx-Ansatz ist sauberer für kurzlebige CI-Runner; die globale Installation ist geringfügig schneller, wenn Sie sie zwischen den Läufen cachen.

Abrufen Ihres Zugriffstokens und der Szenario-ID

Die CLI muss zwei Dinge wissen: welches Szenario ausgeführt werden soll und dass sie es ausführen darf. Apidog generiert beides für Sie, sodass Sie nicht in der Benutzeroberfläche suchen müssen.

Öffnen Sie das Testszenario, das Sie automatisieren möchten. Wechseln Sie zum CI/CD-Tab. Wählen Sie die Kommandozeilenoption, klicken Sie dann auf „Zugriffstoken hinzufügen“ und „Token generieren“. Apidog erstellt den vollständigen apidog run-Befehl für Sie, wobei das Zugriffstoken, die Szenario-ID und die Umgebungs-ID bereits ausgefüllt sind. Klicken Sie auf den Befehl, um ihn zu kopieren.

Dieser generierte Befehl ist der kanonische Ausgangspunkt. Er sieht so aus:

apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,cli

Die Zahlen sind reale IDs aus Ihrem Projekt. 605067 ist die Testszenario-ID. 1629989 ist die Umgebungs-ID. Sie werden diese fast nie manuell eingeben; Sie kopieren sie einmal aus dem CI/CD-Tab und parametrisieren dann das Token.

Eine Regel, die es wert ist, frühzeitig genannt zu werden: Behandeln Sie das Zugriffstoken wie ein Passwort. Fügen Sie es nicht in eine committete Konfigurationsdatei oder eine öffentliche Pipeline-Definition ein. Speichern Sie es als Geheimnis in Ihrem CI-System und referenzieren Sie es als Umgebungsvariable. Jedes Beispiel unten verwendet aus genau diesem Grund $APIDOG_ACCESS_TOKEN.

Der Befehl apidog run, Flag für Flag

Die gesamte CLI dreht sich um einen Befehl. Hier ist die vollständige Optionen-Übersicht, gruppiert nach dem, was jede Gruppe steuert.

Auswahl dessen, was ausgeführt werden soll

Sie wählen eine von -t, -f oder --test-suite, je nach Umfang. Ein einzelnes Szenario für einen fokussierten Smoke-Test, ein Ordner für einen Funktionsbereich, eine Testsuite, wenn Sie eine kuratierte Sammlung von Szenarien als eine logische Aufgabe zusammen ausführen möchten.

Authentifizierung

Dies ist das eine Flag, das jeder CI-Befehl benötigt. Übergeben Sie es aus einem Geheimnis, niemals inline.

Umgebung und Iteration

Das Umgebungs-Flag ist die Art und Weise, wie Sie dasselbe Szenario in einem Pull-Request-Check auf Staging und in einem Post-Deploy-Smoke-Test auf Produktion richten, ohne das Szenario zu duplizieren. Iterationsdaten sind die Art und Weise, wie Sie ein Szenario über fünfzig Zeilen Eingabe ausführen und jede Zeile als separaten Durchlauf behandeln. Wir behandeln das datengesteuerte Muster ausführlicher im Leitfaden zum Skalieren des automatisierten API-Tests mit Testsuiten.

Berichte

Hier verdient die CLI ihren Platz in einer Pipeline. Übergeben Sie mehrere Formate gleichzeitig, durch Kommas getrennt:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -r html,junit --out-dir ./test-reports

cli liefert Ihnen eine lesbare Terminalausgabe für Menschen, die das Build-Protokoll lesen. html erzeugt einen eigenständigen Bericht, den Sie als Build-Artefakt archivieren und in einem Browser öffnen können. junit gibt XML im Standard-JUnit-Format aus, das fast jedes CI-Dashboard in einen Pass/Fail-Baum parsen kann. json liefert Ihnen das rohe strukturierte Ergebnis, wenn Sie es nachbearbeiten möchten.

Fehlerbehandlung und Beendigungsverhalten

--on-error steuert, was während eines Szenarios passiert. end stoppt die Ausführung beim ersten Fehler, was Sie normalerweise für einen schnell fehlschlagenden Smoke-Test wünschen. continue führt jeden Schritt aus, sodass Sie alle Fehler in einem Bericht sehen. ignore ist für den seltenen Fall, dass ein Schritt bekanntermaßen instabil ist und Sie nicht möchten, dass er die Ausführung abbricht.

TLS und Zertifikate

Verwenden Sie diese, wenn Sie Endpunkte hinter gegenseitigem TLS oder mit internen CA-Ketten testen. Greifen Sie nur bei vertrauenswürdigen internen Hosts, bei denen das Zertifikat selbstsigniert ist, auf -k zurück; niemals bei öffentlichen Hosts.

Ausgabe und Diagnose

--verbose ist Ihr erster Schritt, wenn ein Test lokal besteht, aber in CI fehlschlägt; es zeigt Ihnen die genaue Anfrage, die der Runner gesendet hat, und die genaue Antwort, die er erhalten hat. --silent ist für laute nächtliche Aufträge, bei denen Sie sich nur um den Exit-Code und den gespeicherten Bericht kümmern.

Exit-Codes: Der Teil, der CI funktioniert

Ein Test-Runner ist in einer Pipeline nur nützlich, wenn er der Pipeline mitteilt, ob die Tests bestanden wurden. Die Apidog CLI tut dies auf die Weise, wie es jedes wohlverhaltende Kommandozeilen-Tool tut: Sie beendet sich mit dem Code 0, wenn jede Zusicherung bestanden wird, und mit einem Code ungleich Null, wenn etwas fehlschlägt.

Dieses einzelne Verhalten macht apidog run zu einem Qualitäts-Gate. CI-Systeme lesen den Exit-Code jedes Schritts. Ein Exit-Code ungleich Null markiert den Schritt als fehlgeschlagen, was den Job fehlschlagen lässt, was das Mergen oder den Deploy blockiert. Sie konfigurieren nichts Zusätzliches. Solange der Schritt apidog run in Ihrer Pipeline ist, stoppt ein fehlgeschlagener Test die Linie.

Sie können dies mit --on-error gestalten. Das Standardverhalten schlägt bei der ersten fehlerhaften Zusicherung fehl, was ein schnelles Feedback ermöglicht. Wechseln Sie zu --on-error continue, wenn Sie lieber jeden Fehler in einem Bericht sehen möchten, bevor der Build rot wird. In jedem Fall endet der Lauf immer noch mit einem Exit-Code ungleich Null, wenn etwas fehlgeschlagen ist, sodass das Gate hält.

Ausführung in GitHub Actions

vollständiger Workflow, der ein Apidog-Szenario bei jedem Pull Request ausführt und den Bericht als Artefakt veröffentlicht.

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 \
 -n 1 \
 -r html,junit \
 --out-dir ./apidog-reports
 env:
 APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

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

Das Token befindet sich in den Repository-Geheimnissen und erreicht den Schritt als Umgebungsvariable. Das if: always() beim Upload-Schritt bedeutet, dass Sie den Bericht auch dann erhalten, wenn die Tests fehlschlagen, was genau dann der Fall ist, wenn Sie ihn lesen möchten. Wenn ein Test fehlschlägt, beendet sich der apidog run-Schritt mit einem Exit-Code ungleich Null, der Job wird rot und der PR zeigt eine fehlgeschlagene Überprüfung an.

Ausführung in GitLab CI

Dasselbe Muster in .gitlab-ci.yml:

stages:
 - test

api-tests:
 stage: test
 image: node:20
 script:
 - npm install -g apidog-cli
 - >
 apidog run
 --access-token "$APIDOG_ACCESS_TOKEN"
 -t 605067
 -e 1629989
 -r junit,cli
 --out-dir ./apidog-reports
 artifacts:
 when: always
 paths:
 - apidog-reports/
 reports:
 junit: apidog-reports/*.xml

Zwei Dinge sind zu beachten. Speichern Sie APIDOG_ACCESS_TOKEN als maskierte, geschützte CI/CD-Variable unter „Einstellungen“, nicht in der Datei. Und der Block reports: junit: weist GitLab an, das JUnit-XML zu parsen und die Ergebnisse im Merge-Request-Widget anzuzeigen, sodass ein Prüfer sieht, welche Zusicherungen fehlgeschlagen sind, ohne etwas herunterladen zu müssen.

Ausführung in Jenkins

In einer deklarativen Pipeline speichern Sie das Token als Jenkins-Berechtigungsnachweis oder globale Umgebungsvariable und rufen dann die CLI in einer Stufe auf:

pipeline {
 agent any
 environment {
 APIDOG_ACCESS_TOKEN = credentials('apidog-access-token')
 }
 stages {
 stage('API tests') {
 steps {
 sh 'npm install -g apidog-cli'
 sh 'apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit --out-dir apidog-reports'
 }
 }
 }
 post {
 always {
 junit 'apidog-reports/*.xml'
 archiveArtifacts artifacts: 'apidog-reports/', allowEmptyArchive: true
 }
 }
}

Wenn Ihre Build-Agenten die CLI bereits installiert und gecacht haben, löschen Sie die Zeile npm install und rufen Sie apidog run direkt auf. Der junit-Schritt im post-Block speist das XML in die Jenkins-Test-Trenddiagramme ein; archiveArtifacts hält den HTML-Bericht an den Build angehängt. Wenn Sie Jenkins mit anderen Runnern vergleichen, deckt der Vergleich in ReadyAPI Jenkins CI-Setup und eine einfachere Alternative die Kompromisse ab.

Gängige Muster und Rezepte

Smoke-Test nach der Bereitstellung. Führen Sie ein schnelles Szenario nach einem Release gegen die Produktion aus, das auf die Produktionsumgebung abzielt:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e <prodEnvId> -r cli --on-error end

Komplette Regression jede Nacht. Führen Sie einen ganzen Ordner von Szenarien nach einem Zeitplan aus, wobei alle Fehler in einem Bericht gesammelt werden:

apidog run --access-token $APIDOG_ACCESS_TOKEN -f <folderId> -r html,junit --on-error continue --out-dir ./nightly-reports

Datengesteuerter Lauf. Durchlaufen Sie ein Szenario über eine CSV-Datei mit Testfällen:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -d ./test-data.csv -r junit

Branchespezifische Überprüfung. Führen Sie die Szenarien so aus, wie sie auf einem Feature-Branch existieren, nicht auf main:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 --branch feature-payments -e 1629989 -r cli

Einen nur in CI auftretenden Fehler debuggen. Wenn ein Szenario lokal besteht, aber in der Pipeline fehlschlägt, fügen Sie --verbose hinzu, um die genaue Anfrage auf Wire-Ebene und die genaue Antwort des Runners zu sehen.

Fehlerbehebung

Authentifizierungsfehler. Wenn der Lauf mit einem Authentifizierungsfehler fehlschlägt, ist das Token falsch, abgelaufen oder erreicht den Befehl nicht. Führen Sie eine maskierte Überprüfung (niemals das vollständige Token) durch und bestätigen Sie, dass Ihr CI-Geheimnis tatsächlich ausgefüllt ist. Generieren Sie das Token bei Bedarf aus dem CI/CD-Tab des Szenarios neu.

„Szenario nicht gefunden.“ Die Szenario-ID, Projekt-ID oder der Branch stimmen nicht überein. Kopieren Sie den Befehl aus dem CI/CD-Tab erneut, um sicherzustellen, dass die IDs aktuell sind, und bestätigen Sie, dass --branch auf das erwartete Ziel verweist.

Tests bestehen lokal, schlagen aber in CI fehl. Fast immer ein Umgebungsunterschied. Der CI-Runner kann eine andere -e-Umgebung ansteuern, einen Host erreichen, den er nicht erreichen kann, oder es fehlt eine Variable, von der Ihr Szenario abhängt. Führen Sie den Test mit --verbose aus und vergleichen Sie die vom CI-Runner gesendete Anfrage mit der, die Sie lokal senden.

Netzwerk- oder TLS-Fehler bei internen Hosts. Wenn Ihr Endpunkt eine interne CA verwendet, übergeben Sie --ssl-extra-ca-certs. Verwenden Sie -k nur als letzten Ausweg bei vertrauenswürdigen internen Hosts, bei denen das Zertifikat selbstsigniert ist.

Der Build bleibt grün, obwohl ein Test fehlschlagen sollte. Vergewissern Sie sich, dass der Exit-Code des Schritts apidog run tatsächlich in CI ankommt. Wenn Sie ihn in eine Shell-Pipeline eingebunden oder || true angehängt haben, wird der Exit-Code ungleich Null verschluckt und das Gate funktioniert nicht mehr. Entfernen Sie alles, was den Exit-Code maskiert.

Wie die Apidog CLI in einen echten Workflow passt

Die CLI ist ein Teil einer Schleife. Sie entwerfen und debuggen Anfragen in der Apidog-App. Sie verketten sie zu einem Szenario mit Zusicherungen. Sie committen Ihre Arbeit, und die CLI führt dieses Szenario in CI bei jeder Änderung aus. Wenn etwas schiefgeht, sagt Ihnen der Bericht, welche Zusicherung fehlgeschlagen ist, und der Exit-Code stoppt den Deploy. Sie beheben es, pushen erneut, und dasselbe Gate bestätigt die Behebung.

Der Vorteil, Tests visuell zu erstellen und sie kopflos auszuführen, besteht darin, dass niemand zwei Darstellungen desselben Tests pflegen muss. Das Szenario im Projekt ist der Test. Die CLI führt ihn einfach dort aus, wo ein Mensch nicht sein kann. Das ist ein anderes Modell als Skript-First-Runner, bei denen der Test und seine Ausführung dieselbe zerbrechliche Datei sind, und es ist ein großer Teil dessen, warum Teams zu Apidog als Postman-Alternative für API-Tests wechseln.

Wenn Sie die Tests noch nicht erstellt haben, beginnen Sie in der App, bringen Sie ein Szenario zum Laufen und verbinden Sie dann den CLI-Befehl über den CI/CD-Tab. Laden Sie Apidog herunter, um Ihr erstes automatisiertes Szenario einzurichten, und Sie werden es noch am selben Nachmittag in Ihrer Pipeline haben.

Häufig gestellte Fragen

Ist die Apidog CLI kostenlos? Die CLI selbst ist ein kostenloses npm-Paket. Sie installieren es mit npm install -g apidog-cli. Sie führt die Testszenarien aus Ihrem Apidog-Projekt aus, sodass das, was Sie ausführen können, von Ihrem Apidog-Plan abhängt, aber der Kommandozeilen-Runner ist kein separates kostenpflichtiges Produkt.

Muss ich meine Tests als Code umschreiben, um die CLI zu verwenden? Nein. Das ist der Hauptunterschied zu Skript-First-Runnern. Sie erstellen Szenarien visuell in Apidog, und die CLI führt sie anhand der ID aus. Das Szenario ist der Test; die CLI ist nur der Ausführer.

Was ist der Unterschied zwischen der Apidog CLI und Newman? Newman führt Postman-Sammlungen von der Kommandozeile aus. Die Apidog CLI führt Apidog-Testszenarien aus. Die Rollen sind parallel, aber der Apidog-Runner führt Szenarien aus, die Sie in der Apidog-App erstellt haben, und wird als einzelnes apidog-cli-Paket ausgeliefert. Siehe Postman CLI vs. Newman für die Postman-Seite dieses Vergleichs.

Welches Berichtsformat sollte ich in CI verwenden? Verwenden Sie junit für das maschinenlesbare Ergebnis, das Ihr CI-Dashboard in einen Pass/Fail-Baum parst, und fügen Sie html hinzu, wenn Sie einen durchsuchbaren Bericht als Build-Artefakt speichern möchten. Eine gängige Wahl ist -r html,junit. Behalten Sie auch cli bei, wenn Sie eine lesbare Ausgabe im Build-Protokoll wünschen.

Wie lässt die CLI einen Build fehlschlagen? Durch ihren Exit-Code. Wenn eine Zusicherung fehlschlägt, beendet sich apidog run mit einem Exit-Code ungleich Null. CI-Systeme lesen diesen Exit-Code, markieren den Schritt als fehlgeschlagen und blockieren den Merge oder den Deploy. Sie konfigurieren nichts Zusätzliches, damit dies funktioniert.

Kann ich die CLI ausführen, ohne sie global zu installieren? Ja. Verwenden Sie npx apidog-cli run ..., um sie ohne eine dauerhafte globale Installation auszuführen, was bei kurzlebigen CI-Runnern praktisch ist.

Welche Node.js-Version benötige ich? Node.js v16 oder höher. Jedes moderne CI-Image mit Node 16+ erfüllt bereits die Anforderung.

Woher bekomme ich das Zugriffstoken und die Szenario-ID? Beides erhalten Sie über den CI/CD-Tab des Testszenarios in Apidog. Wählen Sie die Kommandozeilenoption, generieren Sie ein Zugriffstoken und kopieren Sie den vollständigen apidog run-Befehl, den Apidog für Sie mit bereits ausgefüllten IDs erstellt. Verschieben Sie das Token dann in ein CI-Geheimnis.