GitHub Actions · presupuesto, consumo y workflows operativos

GitHub Actions · presupuesto y workflows

Estado operativo del consumo GitHub Actions de la cuenta CreaRackSL (User account, plan Pro). Inventario completo de los 18 workflows activos (workspace + CreaRack-Pro), optimizaciones acumuladas y procedimiento ante alertas de uso. Documento de referencia para decidir cambios futuros: si vuelves a plantearte mejorar el consumo, este es tu punto de partida.

Plan + spending limit (estado 2026-05-16)

Inventario de workflows (18 totales · audit s66 2026-05-16)

Workspace CreaRackSL/CreaRackSL-workspace · 13 workflows

CreaRack-Pro CreaRackSL/CreaRack-Pro · 5 workflows

Consumo histórico y optimizaciones acumuladas

Mayo 2026 (1-13) · pre-optims s60

• Workspace: 784 runs / 872 min wall-clock.
• CreaRack-Pro: 347 runs / 1055 min wall-clock (CI top consumer ~1000 min con 4 jobs paralelos).
• Total billable estimado: 2763 min / 3000 (reportado por GitHub al 13-may).

Optimizaciones aplicadas s60 (13-05-2026) · ~400-450 min/mes ahorrados

1. cf-pages-deploy.yml workspace · concurrency cancel-in-progress: true → coalesce rachas de 3-6 commits del bot Bibliotecario · ~150 min/mes.
2. post-merge-ingest.yml workspace · filtro !startsWith('wiki(') → bot ya no se dispara a sí mismo · ~97 min/mes + tokens LLM Anthropic.
3. push-drift.yml CreaRack-Pro · paths-ignore docs/configs/CHANGELOG · ~150-200 min/mes (cron diario 04:15 sigue como safety net).
4. wiki-curator.yml workspace · cron diario → L+J · ahorra ~70% del coste Curator.

s65 (15-05-2026) · emergencia · cap hit pese a optims s60

Acumulación de actividad intensa (19 PRs en 4 días s61-s64 · cron wiki-drift-check nuevo s62) llevó al cap al 100% el 15-05-2026. Salvados por $5 spending limit ya activo (overage $1.04).

Acción temporal aplicada al cierre s65 (commit workspace 1b97de8):

• Var BIBLIOTECARIO_PAUSADO=true seteada → cubrió 5 crons que sí respetaban la var.
• 5 crons que NO la respetaban (bib-reindex-ts, drift-cron, wiki-catalog, wiki-utility, wiki-weekly-report) comentados de emergencia en yaml.

Optimizaciones normalizadas s66 (16-05-2026) · ~600-800 min/mes adicionales

Cierre del PRIMER TEMA arrastrado de s65. 2 PRs: workspace #43 + CreaRack-Pro #35.

Ahorro acumulado total (s60 + s66): ~1000-1200 min/mes liberados del cap 3000.

Multiplicador silencioso del Bibliotecario (audit s60)

Cuando un push humano dispara Bibliotecario-Ingest, el bot puede crear N commits autónomos (wiki(create|update|catalog|archive-query|weekly-report|fix|archive):) que disparan otra vez CF Pages Deploy + Bibliotecario-Ingest.

Cada wiki creada = 2 runs adicionales mínimo. En mayo 1-13: 129 commits autónomos del bot → ~258 runs adicionales solo del multiplicador.

Mitigaciones activas:

• post-merge-ingest.yml filtra wiki( (s60) → el bot no se dispara a sí mismo.
• cf-pages-deploy.yml con concurrency cancel-in-progress: true (s60) → si hay rachas, solo se completa el último deploy.

Toggle de pausa global BIBLIOTECARIO_PAUSADO

Cómo usarlo:

# Pausar todos los crons del Bibliotecario (10 crons workspace)
gh variable set BIBLIOTECARIO_PAUSADO --body true --repo CreaRackSL/CreaRackSL-workspace

# Reactivar
gh variable delete BIBLIOTECARIO_PAUSADO --repo CreaRackSL/CreaRackSL-workspace

Patrón canónico (cubre los 10 crons del Bibliotecario desde s66):

jobs:
  <job>:
    if: ${{ vars.BIBLIOTECARIO_PAUSADO != 'true' }}

Cuando la var no existe, vars.BIBLIOTECARIO_PAUSADO != 'true' evalúa a true y el job corre (estado normal).

Cuándo pausar:

• Hit del cap antes de fin de mes (como s65).
• Sesiones intensivas con muchos PRs en pocos días (s61-s64 patrón).
• Mantenimiento BD D1 o handlers MCP que no quieres re-disparar mientras tocas el código.

Procedimiento ante alerta de uso alto

1. Identificar top consumer:

   gh api repos/CreaRackSL/CreaRackSL-workspace/actions/runs --paginate \
     | jq '.workflow_runs | group_by(.name) | map({name: .[0].name, count: length})'

2. Sospechar del multiplicador del bot:

   git -C C:/dev/CreaRackSL-workspace log --since='1 month ago' --pretty='%s' | grep -E '^wiki\(' | wc -l

   Si >100/mes, el multiplicador silencioso está activo y las mitigaciones s60 deberían estar activas.
3. Verificar optims activas:

   grep -r "concurrency" .github/workflows/cf-pages-deploy.yml
   grep -r "startsWith.*wiki" .github/workflows/post-merge-ingest.yml
   grep -r "paths-ignore" .github/workflows/push-drift.yml
   grep -r "paths-ignore" .github/workflows/ci.yml  # CreaRack-Pro

4. Pausa inmediata si rompe operativa:

   gh variable set BIBLIOTECARIO_PAUSADO --body true --repo CreaRackSL/CreaRackSL-workspace

5. Investigar causa raíz (ver Ideas futuras abajo).

Ideas futuras (cuando vuelvas a plantearte mejorar)

Áreas con margen adicional sin tocar la calidad operativa:

Cuándo activar estas:

• Si vuelves a alcanzar 80% del cap antes del día 25 del mes.
• Si proyectas un mes con >25 PRs (sesiones arquitectónicas s61-s64 tipo).
• Si Dani entra a fase intensa de desarrollo paralelo (más pushes).

Lo que NO se ha optimizado y por qué

• CI CreaRack-Pro 4 jobs paralelos en PR: deliberado, son gates de seguridad antes del merge. Refactorizar para serializar daría min pero más lento por PR.
• CF Pages Deploy: ya tiene concurrency cancel-in-progress. Más allá rompería deploys legítimos del usuario.
• Bibliotecario-Ingest post-merge: necesita correr en cada push de código real. Filtro wiki( ya neutralizó el bucle del bot.
• bib-reindex-ts push trigger: paths estrechos ya. Quitarlo rompería el flujo “push código TS → grafo fresco al instante”.

Véase también

• [[ia-tech—automatismos—metodo—ci-workflows]]
• [[ia-tech—automatismos—metodo—cf-pages-deploy]]
• [[ia-tech—automatismos—metodo—bibliotecario-procesos]]
• [[ia-tech—inventario-automatismos]]