Environments en GitHub Actions: prod no es un string, es un gate

environment: production en el YAML nombra un Environment. Las reglas (reviewers, wait timer, branch allowed) se configuran en Settings → Environments. Si no existe, GitHub puede crear uno vacío sin protection.

No sustituye GITHUB_TOKEN permissions: un token mínimo sigue haciendo falta. El curso instalar un agente no cubre Environments. gh pr no aprueba un deploy.

Receta

deploy:
  environment:
    name: production
    url: https://agente-ia.dev
  needs: build
  runs-on: ubuntu-latest
  steps:
    - run: echo deploy

Secrets de Environment (secrets.PROD_TOKEN) no están en el job si el job no declara ese environment. Un agente que copia secrets.PROD_TOKEN en el job de test los deja vacíos o, peor, pide copiarlos a repo secrets.

Qué no hacer

• Inventar environment: prod y production en workflows distintos. Un nombre, uno.
• Poner environment en el job de lint. Cada wait timer cobra minutos de gente.
• Bypass de required reviewers porque el agente “tiene prisa”. En orgs con policy, no puede.

Public repos: protection rules de Environment tienen límites (GitHub documenta cuáles planes). No prometas reviewers en un fork público gratis si el plan no los da.

Receta AGENTS.md

Deploy jobs use jobs.<id>.environment with a real Environment in repo Settings.
Do not invent extra environment names.
Do not put Environment secrets on test jobs.
Do not bypass required reviewers.

FAQ

¿url? Opcional; sale en el UI de deployments. No es un deploy por sí sola.

¿Concurrency? Otro eje. Environment no cancela runs; concurrency sí.

¿Self-hosted? El Environment no mueve el runner. runs-on aparte.

Verificado 2026-09-03 contra GitHub Docs using environments for deployment y workflow syntax jobs.<job_id>.environment.