Simulationen aus GitHub

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:
    types: [opened, synchronize, reopened, closed]

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://{label}.api.mockz.io - der Default-Branch
• https://{label}-pr{nummer}.api.mockz.io - ein Pull Request
• https://{label}-{branch}.api.mockz.io - jeder andere Branch, den der Workflow deployt

Das Label ist der Name des Repositorys oder der Name, den der Input host anfragt. Hat schon eine andere Simulation diesen Namen, bekommt deine eine Zahl dahinter: petstore-2.

Der Host eines Branches trägt dessen Namen in Kleinbuchstaben, ohne alles außer Buchstaben und Ziffern: feature/checkout auf petstore antwortet unter https://petstore-featurecheckout.api.mockz.io. Der Lauf schlägt fehl und sagt warum, wenn der Branch-Name:

• keine Buchstaben oder Ziffern mehr übrig hat
• wie ein Pull Request aussieht, pr und Ziffern
• den Host länger als 63 Zeichen macht
• einen Host ergibt, der schon belegt ist, von einem anderen aktiven Branch oder einer anderen Simulation

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

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.