GitHub Action

Aktualisiert 31. Aug. 2026·4 Min. Lesezeit

Zwei Actions veröffentlichen ein Repository auf Mockzilla. Beide nehmen dieselben Eingaben, beide enden mit einer Live-URL, und beide sind ein Schritt in einem Workflow, den du schon hast.

mockzilla/actions/portable@v1 packt die Service-Ordner in deinem Repository und lädt sie hoch.
mockzilla/actions/codegen@v1 baut den Go-Server des Repositorys und lädt das Binary hoch. Sie braucht eine go.mod im Wurzelverzeichnis und ein cmd/server-Paket.

Siehe Simulationen aus GitHub dafür, was eine Repository-Simulation ist und wie der erste Push sie registriert.

Der Workflow

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/portable@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Tausche portable@v1 gegen codegen@v1, der Rest bleibt, wie er ist.

Beide Berechtigungen verdienen ihren Platz. contents: read ist für den Checkout. pull-requests: write lässt die Action die URL am Pull Request posten.

Führe closed unter types auf, wie oben. Ein Workflow, der nur pull_request: sagt, läuft beim Schließen eines Pull Requests nie, sein Deployment bleibt also stehen, statt abgebaut zu werden.

Eingaben

Eingabe	Was sie tut
`token`	Pflicht. Das `GITHUB_TOKEN` des Workflows. Es belegt, zu welchem Repository der Lauf gehört.
`region`	Ein Wunsch für den ersten Deploy. Ist die Region voll, wird die nächstgelegene verfügbare genommen. Sobald die Simulation existiert, 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 den API-Explorer. Gib das Passwort als Repository-Secret; es wird gehasht gespeichert und nie geloggt.
`allowed-ips`	Ein JSON-Array von CIDRs, die die Simulation erreichen dürfen, etwa `["203.0.113.0/24"]`. Braucht einen Plan, der eine IP-Freigabeliste erlaubt.
`timeout-minutes`	Wie lange auf das Deployment gewartet wird, bevor der Schritt scheitert. Standard `5`.
`delete`	`true` entfernt die Simulationen dieses Repositorys.
`services-dir`	Nur portable. Wo die Service-Ordner liegen. Standard `services`.

Zugangsdaten und Freigabeliste sind dieselben Einstellungen, die auch die App führt.

Nicht jeder Plan erlaubt eine IP-Freigabeliste. Wo deiner das nicht tut, wird allowed-ips ignoriert: Der Lauf sagt es, und der Deploy geht weiter, die Simulation antwortet also allen.

Siehe Zugriffskontrolle.

Was der Lauf zurückgibt

Der Schritt wartet auf das Deployment, prüft alle 15 Sekunden und meldet an vier Stellen:

Die Ausgabe url, für spätere Schritte im selben Job.
Die Job-Zusammenfassung, eine Zeile mit der Live-URL.
Ein Kommentar am Pull Request, bei jedem weiteren Push an Ort und Stelle bearbeitet, der Thread behält also einen Kommentar, statt einen pro Lauf zu sammeln.
Annotationen für alles, was nicht fatal ist, die ignorierte Freigabeliste von oben eingeschlossen.

Lies die URL in einem späteren Schritt über die Ausgabe:

- uses: mockzilla/actions/portable@v1
  id: mockzilla
  with:
    token: ${{ secrets.GITHUB_TOKEN }}
- run: curl -sf "${{ steps.mockzilla.outputs.url }}/petstore/pets"

Eine URL pro Branch

Wo ein Push landet, hängt vom Branch ab, aus dem er kam:

Der Default-Branch antwortet unter https://api.mockz.io/gh/{org}/{repo}/.
Jeder andere Branch antwortet unter https://api.mockz.io/gh/{org}/{repo}/{branch}/.
Ein Pull Request antwortet unter dem Namen seines Quell-Branches, also unter derselben Adresse, die dieser Branch ohnehin nutzt.

Halte Branch-Namen flach. Ein Branch namens feature/checkout wird deployt, aber Aufrufe an seine URL beantwortet der Default-Branch, nicht er selbst.

Wird ein Pull Request geschlossen, wird sein Deployment abgebaut. Branch-Deployments zählen gegen deinen Plan, solange es sie gibt; ein Workflow, der auf closed hört, hält diese Zahl also ehrlich.

Siehe Verbrauch und Limits.

Ein Repository entfernen

- uses: mockzilla/actions/portable@v1
  with:
    token: ${{ secrets.GITHUB_TOKEN }}
    delete: true

Der Schritt überspringt das Veröffentlichen und entfernt jede Mock-API, die dieses Repository hat. Führe ihn aus einem manuellen workflow_dispatch-Workflow aus, wenn du das Repository trennen oder einen Simulationsplatz für ein anderes freimachen willst.

Wenn ein Lauf scheitert

Der Schritt scheitert mit einer Meldung, und an einem Pull Request wird diese Meldung als Kommentar gepostet. Was dir begegnet:

Ein Limit ist voll. Simulationen, Branch-Deployments, Speicher, das monatliche Build-Kontingent oder der monatliche Datentransfer. Die Meldung nennt jeweils, welches, und verlinkt auf deinen Plan.
Repository- und Branch-Name sind zusammen zu lang. Kürze einen von beiden und pushe erneut.
environment wurde abgelehnt. Es muss ein JSON-Objekt mit Strings als Schlüsseln und Werten sein, und ein paar Namen sind für die Laufzeit reserviert. Die Meldung nennt, was abgelehnt wurde.
Das Deployment wurde nicht rechtzeitig aktiv. Setze timeout-minutes über den Standard von 5.
Keine go.mod im Wurzelverzeichnis, bei der Codegen-Action. Sie baut ./cmd/server aus dem Wurzelverzeichnis und hört auf, wenn es nichts zu bauen gibt.

Wie es weitergeht

Die Actions sind ein öffentliches Repository, was in deiner CI läuft, ist also lesbar: mockzilla/actions.