GitHub Action

Actualizado el 29 sept 2026·5 min de lectura

Dos actions publican un repositorio en Mockzilla. Las dos toman las mismas entradas, las dos terminan con una URL en marcha, y las dos son un paso dentro de un workflow que ya tienes.

mockzilla/actions@v1 empaqueta las carpetas de servicio de tu repositorio y las sube.
mockzilla/actions/codegen@v1 construye el servidor Go del repositorio y sube el binario. Necesita un go.mod en la raíz y un paquete cmd/server.

Consulta Simulaciones desde GitHub para saber qué es una simulación respaldada por un repositorio y cómo la registra el primer push.

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

Cambia portable@v1 por codegen@v1 y el resto queda igual.

Los dos permisos se ganan su lugar. contents: read es para el checkout. pull-requests: write deja que la action publique la URL en el pull request.

Lista closed en types, como arriba. Un workflow que dice solo pull_request: nunca corre cuando se cierra un pull request, así que su despliegue queda en pie en lugar de darse de baja.

Entradas

Entrada	Qué hace
`token`	Obligatorio. El `GITHUB_TOKEN` del workflow. Prueba a qué repositorio pertenece la ejecución.
`region`	Una preferencia para el primer despliegue. Si esa región está llena, se usa la más cercana disponible. No tiene efecto una vez que la simulación existe.
`environment`	Un objeto JSON de variables de entorno para el runtime.
`host`	El dominio en el que responde la simulación: `mockz.io`, `mockz.net`, `mockz.org`, `mockzilla.org`, `mockzilla.de` o `mockzilla.net`. Con un label delante lo pides: `petstore.mockz.io` responde en `https://petstore.api.mockz.io`. Queda fijo desde el primer despliegue. Por defecto toma el ajuste de la organización, o `mockz.io`.
`basic-auth-user`, `basic-auth-password`	Credenciales para el explorador de API. Pasa la contraseña como secreto del repositorio; se guarda con hash y nunca se registra.
`allowed-ips`	Un arreglo JSON de CIDRs con permiso para llegar a la simulación, como `["203.0.113.0/24"]`. Necesita un plan que permita lista de IP.
`timeout-minutes`	Cuánto esperar el despliegue antes de fallar el paso. Por defecto `5`.
`delete`	`true` elimina las simulaciones de este repositorio.
`services-dir`	Solo portable. Dónde viven las carpetas de servicio. Por defecto `services`.

Las credenciales y la lista de IP son los mismos ajustes que lleva la app.

No todos los planes permiten lista de IP. Donde el tuyo no la permite, allowed-ips se ignora: la ejecución lo dice y el despliegue sigue, así que la simulación le responde a todo el mundo.

Consulta Control de acceso.

Qué devuelve la ejecución

El paso espera el despliegue, comprobando cada 15 segundos, e informa en cuatro lugares:

La salida url, para los pasos posteriores del mismo job.
El resumen del job, una línea con la URL en marcha.
Un comentario en el pull request, editado en su lugar en cada push posterior, así el hilo mantiene un comentario en vez de juntar uno por ejecución.
Anotaciones para todo lo que no sea fatal, incluida la lista de IP ignorada de arriba.

Lee la URL desde un paso posterior con la salida:

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

Una URL por rama

Cada push aterriza en un host propio, con el nombre de donde vino:

La rama por defecto responde en https://{label}.api.mockz.io.
Un pull request responde en https://{label}-pr{numero}.api.mockz.io.
Cualquier otra rama responde en https://{label}-{rama}.api.mockz.io, con el nombre de la rama en minúsculas y sin nada que no sean letras y dígitos: feature/checkout en petstore es https://petstore-featurecheckout.api.mockz.io.

El label es el nombre del repositorio, o el que pide el input host. Si otra simulación ya tiene ese nombre, la tuya lleva un número detrás: petstore-2.

Cerrar un pull request da de baja su despliegue. Los despliegues de rama cuentan contra tu plan mientras existen, así que un workflow que escucha closed mantiene honesto ese número.

Consulta Uso y límites.

Quitar un repositorio

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

El paso se saltea la publicación y elimina cada mock API que tenga este repositorio. Córrelo desde un workflow manual de workflow_dispatch cuando quieras desconectar el repositorio, o para liberar un cupo de simulación para otro.

Cuando una ejecución falla

El paso falla con un mensaje, y en un pull request ese mensaje se publica como comentario. Lo que vas a ver:

Un límite está lleno. Simulaciones, despliegues de rama, almacenamiento, el cupo mensual de builds o la transferencia mensual de datos. Cada uno nombra cuál es y enlaza a tu plan.
Los nombres del repositorio y de la rama son demasiado largos juntos. Acorta cualquiera de los dos y vuelve a hacer push.
El nombre de la rama no da un host. No conserva letras ni dígitos, parece un pull request (pr y dígitos) o hace que el host pase de 63 caracteres. Cambia el nombre de la rama.
El host de la rama ya está en uso. Otra rama activa del repositorio, u otra simulación, ya responde ahí. Cambia el nombre de la rama.
Se rechazó environment. Tiene que ser un objeto JSON con claves y valores de texto, y unos pocos nombres están reservados por el runtime. El mensaje nombra qué rechazó.
El despliegue no llegó a activo a tiempo. Sube timeout-minutes por encima del valor por defecto de 5.
No hay go.mod en la raíz del repositorio, en la action de codegen. Construye ./cmd/server desde la raíz del repositorio y se detiene cuando no hay nada que construir.

A dónde ir después

Las actions son un repositorio público, así que lo que corre en tu CI se puede leer: mockzilla/actions.