Exécution headless et intégration continue

Un scénario construit dans l’interface s’exécute sans fenêtre depuis la ligne de commande. C’est le chemin qui transforme vos tests d’API en étape de pipeline.

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

Édition Pro

L’exécution headless est incluse dans les éditions Pro et Enterprise. Elle requiert un jeton d’organisation, fourni dans la variable d’environnement RESTORM_TOKEN. Voir Plans et capacités.

Les arguments

Argument	Rôle
--open <chemin>, -o	Le projet à ouvrir. Obligatoire avec --run
--run <cible>	Le scénario à exécuter. Sa présence active le mode ligne de commande
--by <name|id>	Comment --run désigne le scénario : par nom (défaut) ou par identifiant
--headless	Aucune fenêtre. Sans lui, la fenêtre s’affiche pendant que le journal défile sur la console
--param nom=valeur	Une valeur pour un paramètre d’entrée du scénario (une boîte Input / Param). Répétable
--all-logs	Inclut les entrées du moteur ; par défaut seules celles de l’action Log sont émises
--out <fichier>	Écrit aussi le journal dans un fichier, au fil de l’eau
--clear-settings, -cls	Réinitialise les préférences avant le lancement

Un --param mal formé (sans =) est signalé sur la sortie d’erreur et ignoré. nom= (valeur vide) est accepté.

Les valeurs sont converties selon le type déclaré du paramètre — voir Variables et données.

--param cible les entrées du scénario, pas les variables d’environnement

--param alimente les boîtes Input / Param déclarées dans le scénario — il ne modifie pas une variable d’environnement. Ainsi, --param status=available ci-dessus ne fonctionne que parce que le scénario expose un paramètre d’entrée nommé status. Vouloir surcharger l’URL de base avec --param baseUrl=… n’aurait aucun effet si baseUrl est une variable d’environnement : une valeur qui vit dans un environnement n’est pas surchargeable en ligne de commande. Pour rendre une telle valeur pilotable depuis la CI, exposez-la en paramètre d’entrée du scénario (une boîte Input / Param) et câblez-la là où vous en avez besoin.

Les codes de sortie

Code	Signification
0	Le scénario s’est terminé correctement
1	Échec, annulation, ou erreur du moteur
2	Cible introuvable, fichier --out inaccessible, ou --run sans --open
3	Droit refusé : RESTORM_TOKEN absent, invalide ou révoqué, plan insuffisant, ou point de vérification injoignable

C’est cette convention qui rend le résultat directement exploitable par un runner de CI.

La sortie

Le journal est écrit sur la sortie standard, une entrée à la fois, dès qu’elle est produite, sous forme de séquence YAML :

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

Les niveaux sont préfixés d’une pastille : ⚪ debug, 🔵 info, 🟠 warn, 🔴 error. Les lignes ne sont jamais coupées — la sortie reste grep-able. Les erreurs partent sur la sortie d’erreur standard.

C’est exactement le texte que produit le bouton « copier le journal » de l’interface : le même format des deux côtés.

Les secrets en CI

Utilisez la source de secret variable d’environnement : le secret est injecté par le coffre de votre CI, Restorm ne fait que le lire, et rien n’est écrit dans le projet. Voir Secrets.

Épinglez la version

Le canal de téléchargement publie des fichiers versionnés (restorm_<version>_amd64.deb) : il n’y a pas d’alias latest. Épinglez la version dans votre pipeline — c’est de toute façon ce qu’on veut en CI, pour qu’une nouvelle version ne change pas le comportement d’un job sans revue. Les noms de fichiers exacts de la dernière version sont listés dans le manifeste latest-linux.yml du même canal.

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' # la version que vous voulez épingler
        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' # la version que vous voulez épingler
  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]

Ce qui change en headless

• Les actions Toast ne font rien ; l’exécution se poursuit normalement.
• Les paramètres ne peuvent pas être demandés interactivement : fournissez-les tous avec --param, ou laissez-les prendre leur valeur par défaut.
• Le serveur MCP ne démarre jamais sur une machine sans affichage, quel que soit le réglage.

Obtenir un jeton

Le jeton RESTORM_TOKEN (préfixé rstk_) se génère depuis le tableau de bord de votre compte. Il est rattaché à l’organisation, pas à une personne : c’est le jeton qu’on met dans le coffre de la CI. Voir Comptes et connexion.