Simulationen aus GitHub

Aktualisiert 7. Sept. 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@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, ein Pull Request eingeschlossen, unter dem Namen des Branches, aus dem er kommt

Halte diese Branch-Namen flach. Ein Branch mit Schrägstrich, etwa feature/checkout, wird deployt, hat aber keine eigene URL, und Aufrufe an ihn beantwortet der Default-Branch.

Ein Pull Request bekommt seine URL als Kommentar auf den PR, Reviewer klicken also direkt in den geänderten Mock. Ihn zu schließen baut dieses Deployment ab, sofern der Workflow auf geschlossene Pull Requests hört.

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.
`allowed-ips`	Ein JSON-Array von CIDRs, die die Simulation erreichen dürfen. Wird mit Warnung ignoriert, wenn der Plan keine IP-Freigabeliste erlaubt.
`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.