# Ejecutar un Met desde GitHub Actions

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**):

| secreto | qué es |
|---|---|
| `MET_API_KEY` | una key `met_live_` con los scopes que use tu paso |
| `MET_WORKSPACE` | el id numérico del workspace |

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

```yaml
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:

```yaml
      - 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](receta-aprobacion-humana.html) 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:

```bash
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)](cli.html).
- Para reaccionar al final del run en vez de esperarlo dentro del job:
  [recibir eventos firmados](receta-webhooks-firmados.html).