GitHub Action

Atualizado em 29 de set. de 2026·5 min de leitura

Duas actions publicam um repositório no Mockzilla. As duas aceitam as mesmas entradas, as duas terminam com uma URL no ar, e as duas são um passo dentro de um workflow que você já tem.

mockzilla/actions@v1 empacota as pastas de serviço do seu repositório e sobe elas.
mockzilla/actions/codegen@v1 compila o servidor Go do repositório e sobe o binário. Ela precisa de um go.mod na raiz e de um pacote cmd/server.

Veja Simulações do GitHub para saber o que é uma simulação apoiada num repositório e como o primeiro push registra ela.

O 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 }}

Troque portable@v1 por codegen@v1 e o resto fica como está.

As duas permissões ganham o lugar delas. contents: read é para o checkout. pull-requests: write deixa a action publicar a URL no pull request.

Liste closed em types, como acima. Um workflow que diz só pull_request: nunca roda quando um pull request fecha, então o deploy dele fica de pé em vez de ser derrubado.

Entradas

Entrada	O que faz
`token`	Obrigatório. O `GITHUB_TOKEN` do workflow. Ele prova a qual repositório a execução pertence.
`region`	Uma preferência para o primeiro deploy. Se aquela região estiver cheia, a mais próxima disponível entra no lugar. Não tem efeito depois que a simulação existe.
`environment`	Um objeto JSON de variáveis de ambiente para o runtime.
`host`	O domínio em que a simulação responde: `mockz.io`, `mockz.net`, `mockz.org`, `mockzilla.org`, `mockzilla.de` ou `mockzilla.net`. Com um label na frente você pede ele: `petstore.mockz.io` responde em `https://petstore.api.mockz.io`. Fica fixo a partir do primeiro deploy. Por padrão pega a configuração da organização, ou `mockz.io`.
`basic-auth-user`, `basic-auth-password`	Credenciais para o explorador de API. Passe a senha como secret do repositório; ela é guardada com hash e nunca vai para o log.
`allowed-ips`	Um array JSON de CIDRs com permissão de alcançar a simulação, tipo `["203.0.113.0/24"]`. Precisa de um plano que permita lista de IP.
`timeout-minutes`	Quanto esperar pelo deploy antes de falhar o passo. Por padrão `5`.
`delete`	`true` remove as simulações deste repositório.
`services-dir`	Só no portable. Onde ficam as pastas de serviço. Por padrão `services`.

As credenciais e a lista de IP são as mesmas configurações que o app carrega.

Nem todo plano permite lista de IP. Onde o seu não permite, o allowed-ips é ignorado: a execução avisa e o deploy continua, então a simulação responde para todo mundo.

Veja Controle de acesso.

O que a execução devolve

O passo espera o deploy, conferindo a cada 15 segundos, e informa em quatro lugares:

A saída url, para os passos seguintes do mesmo job.
O resumo do job, uma linha com a URL no ar.
Um comentário no pull request, editado no lugar a cada push seguinte, então a thread mantém um comentário em vez de juntar um por execução.
Anotações para tudo que não for fatal, incluindo a lista de IP ignorada acima.

Leia a URL de um passo seguinte pela saída:

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

Uma URL por branch

Cada push cai em um host próprio, com o nome de onde ele veio:

A branch padrão responde em https://{label}.api.mockz.io.
Um pull request responde em https://{label}-pr{numero}.api.mockz.io.
Qualquer outra branch responde em https://{label}-{branch}.api.mockz.io, com o nome da branch em minúsculas e sem nada além de letras e dígitos: feature/checkout em petstore é https://petstore-featurecheckout.api.mockz.io.

O label é o nome do repositório, ou o que o input host pede. Se outra simulação já tem esse nome, a sua ganha um número no final: petstore-2.

Fechar um pull request derruba o deploy dele. Os deploys de branch contam no seu plano enquanto existem, então um workflow que escuta closed mantém esse número honesto.

Veja Uso e limites.

Remover um repositório

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

O passo pula a publicação e remove todo mock de API que este repositório tem. Rode ele por um workflow manual de workflow_dispatch quando quiser desconectar o repositório, ou para liberar uma vaga de simulação para outro.

Quando uma execução falha

O passo falha com uma mensagem, e num pull request essa mensagem é publicada como comentário. O que você vai ver:

Um limite está cheio. Simulações, deploys de branch, armazenamento, a cota mensal de builds ou a transferência mensal de dados. Cada um nomeia qual é e leva para o seu plano.
Os nomes do repositório e da branch são longos demais juntos. Encurte um dos dois e dê push de novo.
O nome da branch não dá um host. Não fica com letras nem dígitos, parece um pull request (pr e dígitos) ou deixa o host com mais de 63 caracteres. Renomeie a branch.
O host da branch já está em uso. Outra branch ativa do repositório, ou outra simulação, já responde ali. Renomeie a branch.
O environment foi recusado. Ele tem que ser um objeto JSON com chaves e valores de texto, e alguns poucos nomes são reservados pelo runtime. A mensagem nomeia o que ela recusou.
O deploy não ficou ativo a tempo. Suba o timeout-minutes acima do padrão de 5.
Não tem go.mod na raiz do repositório, na action de codegen. Ela compila ./cmd/server a partir da raiz do repositório e para quando não tem nada para compilar.

Para onde ir agora

As actions são um repositório público, então o que roda no seu CI dá para ler: mockzilla/actions.