GitHub Action

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@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@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.

Eingaben

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

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@v1
  id: mockzilla
  with:
    token: ${{ secrets.GITHUB_TOKEN }}
- run: curl -sf "${{ steps.mockzilla.outputs.url }}/petstore/pets"

Eine URL pro Branch

Jeder Push landet unter einem eigenen Host, benannt nach seiner Herkunft:

• Der Default-Branch antwortet unter https://{label}.api.mockz.io.
• Ein Pull Request antwortet unter https://{label}-pr{nummer}.api.mockz.io.
• Jeder andere Branch antwortet unter https://{label}-{branch}.api.mockz.io, mit dem Branch-Namen in Kleinbuchstaben und ohne alles außer Buchstaben und Ziffern: feature/checkout auf petstore ist https://petstore-featurecheckout.api.mockz.io.

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.

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@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.
• Der Branch-Name ergibt keinen Host. Er hat keine Buchstaben oder Ziffern, sieht wie ein Pull Request aus (pr und Ziffern) oder macht den Host länger als 63 Zeichen. Benenne den Branch um.
• Der Host des Branches ist belegt. Ein anderer aktiver Branch des Repositorys oder eine andere Simulation antwortet schon dort. Benenne den Branch um.
• 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

• Simulationen aus GitHub
• Portable Simulationen
• Codegen-Simulationen

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