Headless-Ausführung und Continuous Integration

Ein in der Oberfläche erstelltes Szenario lässt sich ohne Fenster über die Kommandozeile ausführen. Das ist der Weg, der aus Ihren API-Tests einen Pipeline-Schritt macht.

restorm \
  --open ./projet.restorm \
  --run "Find pets by status" \
  --headless \
  --param status=available

Pro-Edition

Die Headless-Ausführung ist in den Editionen Pro und Enterprise enthalten. Sie erfordert ein Organisations-Token, das über die Umgebungsvariable RESTORM_TOKEN bereitgestellt wird. Siehe Tarife und Funktionsumfang.

Die Argumente

Argument	Rolle
--open <path>, -o	Das zu öffnende Projekt. Bei --run erforderlich
--run <target>	Das auszuführende Szenario. Sein Vorhandensein aktiviert den Kommandozeilenmodus
--by <name|id>	Wie --run das Szenario bezeichnet: nach Name (Standard) oder nach ID
--headless	Kein Fenster. Ohne diese Option wird das Fenster angezeigt, während das Protokoll auf der Konsole mitläuft
--param name=value	Ein Wert für einen Eingabeparameter des Szenarios (einen Input/Param-Baustein). Wiederholbar
--all-logs	Bezieht auch die Einträge der Engine mit ein; standardmäßig werden nur die der Aktion Log ausgegeben
--out <file>	Schreibt das Protokoll zusätzlich laufend in eine Datei
--clear-settings, -cls	Setzt die Einstellungen vor dem Start zurück

Ein fehlerhaft geformtes --param (ohne =) wird auf der Fehlerausgabe gemeldet und ignoriert. name= (leerer Wert) wird akzeptiert.

Die Werte werden gemäß dem deklarierten Typ des Parameters umgewandelt – siehe Variablen und Daten.

--param zielt auf die Eingänge des Szenarios, nicht auf Umgebungsvariablen

--param speist die im Szenario deklarierten Input/Param-Bausteine – es ändert keine Umgebungsvariable. So funktioniert --param status=available oben also nur, weil das Szenario einen Eingabeparameter namens status bereitstellt. Der Versuch, die Basis-URL mit --param baseUrl=… zu überschreiben, hätte keine Wirkung, wenn baseUrl eine Umgebungsvariable ist: Ein Wert, der in einer Umgebung lebt, lässt sich nicht über die Kommandozeile überschreiben. Um einen solchen Wert von der CI aus steuerbar zu machen, stellen Sie ihn als Eingabeparameter des Szenarios bereit (einen Input/Param-Baustein) und verdrahten Sie ihn dort, wo Sie ihn brauchen.

Die Exit-Codes

Code	Bedeutung
0	Das Szenario wurde erfolgreich beendet
1	Fehlschlag, Abbruch oder Engine-Fehler
2	Ziel nicht gefunden, Datei --out nicht erreichbar, oder --run ohne --open
3	Zugriff verweigert: RESTORM_TOKEN fehlt, ungültig oder widerrufen, unzureichender Plan, oder Prüfpunkt nicht erreichbar

Diese Konvention macht das Ergebnis direkt für einen CI-Runner nutzbar.

Die Ausgabe

Das Protokoll wird auf der Standardausgabe geschrieben, jeweils ein Eintrag, sobald er erzeugt wird, als YAML-Sequenz:

- message: "🔵 [2026-07-29 10:30:00.123] Commande créée"
  data: { id: 4271 }

Die Stufen sind durch ein Symbol gekennzeichnet: ⚪ debug, 🔵 info, 🟠 warn, 🔴 error. Zeilen werden nie umgebrochen – die Ausgabe bleibt grep-fähig. Fehler werden auf der Standard-Fehlerausgabe ausgegeben.

Das ist exakt der Text, den die Schaltfläche „Protokoll kopieren“ der Oberfläche erzeugt: auf beiden Seiten dasselbe Format.

Secrets in der CI

Verwenden Sie die Secret-Quelle Umgebungsvariable: Das Secret wird vom Tresor Ihrer CI eingespeist, Restorm liest es nur, und nichts wird in das Projekt geschrieben. Siehe Secrets.

Version fixieren

Der Download-Kanal veröffentlicht versionierte Dateien (restorm_<version>_amd64.deb): Es gibt keinen latest-Alias. Fixieren Sie die Version in Ihrer Pipeline – das ist ohnehin das, was man in der CI will, damit eine neue Version das Verhalten eines Jobs nicht ohne Review verändert. Die genauen Dateinamen der jeweils neuesten Version sind im Manifest latest-linux.yml desselben Kanals aufgeführt.

Restorm auf dem Runner installieren

• Über npm — npm i -g restorm-cli@<version>, dann restorm …. Der offizielle Build wird einmal heruntergeladen, anhand seiner veröffentlichten Prüfsumme verifiziert und zwischengespeichert; spätere Jobs auf derselben Maschine laden nichts mehr. Die Versionsnummer des npm-Pakets ist die Restorm-Version, die es startet — wer die eine festlegt, legt auch die andere fest.
• Über das Systempaket (.deb, .rpm), wie in den Beispielen unten — die bessere Wahl, wenn Sie Ihr eigenes Runner-Image bauen, denn dann lädt der Job überhaupt nichts herunter.

Die offizielle GitHub-Action

Auf GitHub bündelt Monsieur-Dev/restorm-action alles, was diese Seite beschreibt, in einem Schritt: Sie installiert Restorm über restorm-cli (ein prüfsummenverifizierter Download, zwischen Jobs gecacht), kapselt es in xvfb, führt Ihr Szenario headless aus und übersetzt jeden Exit-Code in einen benannten Job-Fehler.

- uses: Monsieur-Dev/restorm-action@v1
  with:
    project: ./api.restorm
    scenario: Smoke tests
    params: |
      status=available
  env:
    RESTORM_TOKEN: ${{ secrets.RESTORM_TOKEN }}

Das Tag der Action pinnt die Restorm-Version (@v1.2.3 führt Restorm 1.2.3 aus), oder übergeben Sie explizit version:. Alle Eingaben sind im README des Repositorys dokumentiert. Das manuelle Rezept unten bleibt für alle, die volle Kontrolle wollen.

GitHub Actions

name: Tests d'API
on: [push]

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

      - name: Installer Restorm
        env:
          RESTORM_VERSION: '1.4.2' # die Version, die Sie fixieren möchten
        run: |
          curl -sSL -o restorm.deb \
            "https://dl.restorm.app/restorm_${RESTORM_VERSION}_amd64.deb"
          sudo apt-get install -y ./restorm.deb

      - name: Exécuter les tests de fumée
        env:
          RESTORM_TOKEN: ${{ secrets.RESTORM_TOKEN }}
          API_TOKEN: ${{ secrets.API_TOKEN }}
        run: |
          xvfb-run -a restorm \
            --open ./api.restorm \
            --run "Find pets by status" \
            --headless \
            --all-logs \
            --out run.log \
            --param status=available

      - name: Publier le journal
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: journal-restorm
          path: run.log

GitLab CI

tests-api:
  image: ubuntu:24.04
  variables:
    RESTORM_TOKEN: $RESTORM_TOKEN
    RESTORM_VERSION: '1.4.2' # die Version, die Sie fixieren möchten
  before_script:
    - apt-get update && apt-get install -y curl xvfb
    - curl -sSL -o restorm.deb "https://dl.restorm.app/restorm_${RESTORM_VERSION}_amd64.deb"
    - apt-get install -y ./restorm.deb
  script:
    - >
      xvfb-run -a restorm
      --open ./api.restorm
      --run "Find pets by status"
      --headless --all-logs --out run.log
      --param status=$PET_STATUS
  artifacts:
    when: always
    paths: [run.log]

Was sich im Headless-Modus ändert

• Toast-Aktionen bewirken nichts; die Ausführung läuft normal weiter.
• Parameter können nicht interaktiv abgefragt werden: Stellen Sie sie alle über --param bereit, oder lassen Sie sie ihren Standardwert annehmen.
• Der MCP-Server startet auf einer Maschine ohne Bildschirm niemals, unabhängig von der Einstellung.

Ein Token erhalten

Das Token RESTORM_TOKEN (mit dem Präfix rstk_) wird über das Dashboard Ihres Kontos erzeugt. Es ist an die Organisation gebunden, nicht an eine Person: Es ist das Token, das man in den Tresor der CI legt. Siehe Konten und Anmeldung.