Simulationen aus GitHub

Aktualisiert 30. Aug. 2026·4 Min. Lesezeit

Eine Simulation aus GitHub macht ein Repository zur Quelle der Wahrheit: Specs, statische Endpunkte und Konfiguration liegen als Dateien, und jeder Push deployt sie. Nichts am Mock ändert sich ohne einen Commit dahinter, und genau das ist der Punkt - Mocks im Code-Review, mit einer URL pro Branch und pro Pull Request.

Vom Push zur URL

Füge einem Workflow einen Schritt hinzu:

name: mockzilla

on:
  push:
    branches: [main]
  pull_request:

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: mockzilla/actions/portable@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Bei jedem Push prüft die Action, dass der Workflow wirklich in deinem Repository läuft, über das normale GITHUB_TOKEN, das GitHub dem Lauf ausstellt - es gibt keinen Mockzilla-Schlüssel anzulegen, und das Token wird einmal gegen GitHubs API verwendet und nie gespeichert. Dann lädt sie den gepackten Inhalt hoch, wartet auf das Deployment und gibt die URL aus:

https://api.mockz.io/gh/{org}/{repo}/ - der Default-Branch
https://api.mockz.io/gh/{org}/{repo}/{branch}/ - jeder andere Branch
https://api.mockz.io/gh/{org}/{repo}/pr-{n}/ - ein Pull Request

Ein Pull Request bekommt seine URL als Kommentar auf den PR, Reviewer klicken also direkt in den geänderten Mock; wird der PR geschlossen, wird sein Deployment von selbst abgebaut.

Kein Konto nötig

Der erste Push aus einem Repository registriert es: Die Simulation existiert und antwortet, bevor sich irgendwer angemeldet hat. Wenn du sie in der App sehen willst - Verlauf, Replays, Verbrauch - melde dich mit GitHub an, und die Simulationen deiner Organisation sind da. Die App zeigt eine Repository-Simulation schreibgeschützt: Ihr Inhalt ändert sich über Commits, nicht über Klicks; Zugriffseinstellungen und Umgebungsvariablen bleiben aber in der App editierbar, für Werte, die nicht in einer Workflow-Datei leben sollen.

Das Repository-Layout

Die Portable-Action veröffentlicht einen Ordner pro Service; das Layout ist dasselbe, das jeder Simulationstyp teilt:

services/
  petstore/
    openapi.yml        # die Spec; jedes *.yml/yaml/json funktioniert
    config.yml         # optional: Upstream, Latenz, Fehler, Mount
    context.yml        # optional: Werte, die generierte Daten formen
    static/
      users/
        get/
          index.json   # GET /petstore/users, von Hand gepinnt
app.yml                # optional: App-weite Einstellungen

Die Codegen-Action deployt stattdessen ein generiertes Go-Projekt aus dem Repository, Handler inklusive.

Siehe Portable Simulationen für das Ordnerformat und Codegen-Simulationen für die generierte Art.

Was die Action annimmt

Eingabe	Was sie tut
`token`	Das `GITHUB_TOKEN` des Workflows; belegt die Repository-Identität. Pflicht.
`region`	Ein Regionswunsch, keine Pflicht: Der erste Deploy versucht sie, und hat die Region keine Kapazität, wird die nächstgelegene verfügbare genommen. Nach dem ersten Deploy ohne Wirkung.
`environment`	Ein JSON-Objekt mit Umgebungsvariablen für die Laufzeit.
`host`	Welcher API-Host die URL bedient. Standard ist die Einstellung der Organisation, sonst `api.mockz.io`.
`basic-auth-user`, `basic-auth-password`	Zugangsdaten für die API-Explorer-UI. Gib das Passwort als GitHub-Secret; es wird gehasht gespeichert und nie geloggt.
`ip-allowlist`	Ein JSON-Array von CIDRs, die die Simulation erreichen dürfen. Wird mit Warnung ignoriert, wenn der Plan das Feature nicht enthält.
`services-dir`	Wo die Service-Ordner liegen. Standard `services`.
`timeout-minutes`	Wie lange auf das Deployment gewartet wird, bevor der Schritt scheitert. Standard 5.
`delete`	`true` entfernt die Simulationen des Repositorys und gibt seinen Platz frei.

Auf Plänen mit einem einzelnen Simulationsplatz belegt ihn ein Repository. Führe die Action mit delete: true aus, um den Platz freizugeben, bevor du ein anderes verbindest.

Offen gebaut

Die Action ist ein öffentliches Repository; was in deiner CI läuft, ist keine Blackbox: Lies sie unter mockzilla/actions. Die Engine, die sie deployt, ist derselbe Open-Source-Mock-Server, auf dem alles andere hier läuft, und das veröffentlichte Layout entspricht dem öffentlichen Template.

Starte vom Template: mockzilla/mockzilla-portable-template

Die vollständige Eingaben-Referenz liegt bei der Action und auf ihrer Doku-Seite.

Siehe GitHub Action.