Ejecutar un Met desde GitHub Actions

Poner un Met dentro de tu pipeline — resumir un despliegue, revisar un cambio o correr una tarea— con el código de salida reflejando el resultado.

El CLI cubre la misma API que el SDK, así que cualquier cosa que hace tu backend la puede hacer un paso de CI. Esta receta corre un Met cuando pasa algo en el repositorio y hace que el pipeline falle si la tarea falló.

Antes de empezar

Guarda dos secretos en el repositorio (Settings → Secrets and variables → Actions):

El CLI lee las dos variables de entorno directamente, así que en CI no hace falta met config set.

1. Un Met que resume lo que se acaba de desplegar

name: Resumen de despliegue

on:
  push:
    branches: [main]

jobs:
  resumir:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 20

      - run: npm i -g @meteor.ia/cli

      - name: Resumir los commits del push
        env:
          MET_API_KEY: ${{ secrets.MET_API_KEY }}
          MET_WORKSPACE: ${{ secrets.MET_WORKSPACE }}
        run: |
          COMMITS=$(git log --format='%s' -20)
          met run "Resume estos commits para el equipo de soporte, en tres viñetas: $COMMITS" \
            --json --no-stream > salida.json
          jq -r '.output' salida.json >> "$GITHUB_STEP_SUMMARY"

--json imprime el run completo en una línea, listo para jq. --no-stream es lo que hace que sirva en CI: sin él, el CLI pinta la respuesta a medida que llega y lo que queda en el log son fragmentos, no un JSON parseable.

2. Una tarea que hace fallar el pipeline

met run ejecuta un Met suelto. Para un procedimiento con pasos —el caso normal cuando el resultado importa— va una tarea, y --wait espera el estado final:

      - name: Revisión previa al release
        env:
          MET_API_KEY: ${{ secrets.MET_API_KEY }}
          MET_WORKSPACE: ${{ secrets.MET_WORKSPACE }}
        run: met tasks run tsk_123 --wait

Con --wait, el código de salida refleja el estado final de la ejecución: si la tarea falla, el paso falla y el pipeline se detiene. Sin --wait, el comando dispara la ejecución y vuelve enseguida con un 0 que solo dice que arrancó.

Ojo con una cosa: si la tarea tiene un paso que espera aprobación de una persona, --wait se queda esperando hasta que alguien decida, y en CI eso es un job colgado hasta el tiempo límite. Las tareas que corren desatendidas no llevan pausas humanas — mira la receta de aprobación para cuándo sí conviene tenerlas.

3. Un vistazo a lo que salió mal

Útil como paso final cuando algo falló, o como job programado:

met runs list --status failed --limit 20

La Energía se consume igual

Un run desde CI cuesta lo mismo que uno desde tu backend, y un workflow que corre en cada push suma rápido. Dos cosas que ayudan: usa una key aparte para CI, y ponle presupuesto — con billing.threshold suscrito te llega un aviso al 50, 80 y 100% en vez de una sorpresa. El consumo por key está en tu panel, en Desarrolladores.

Y después

• Todos los comandos, la configuración y los formatos de salida: CLI (met).
• Para reaccionar al final del run en vez de esperarlo dentro del job: recibir eventos firmados.