coreyhaines31/ci-audit

/ci-audit — Encuentra y corrige el tiempo malgastado en GitHub Actions

Mide primero, luego arregla las pocas cosas que realmente importan. En auditorías reales, la mayor pérdida rara vez fue un conjunto de pruebas lento. Fue un pipeline programado que había fallado todos los días durante meses, un cron cada hora de 30 segundos facturado como 730 minutos al mes, o un SDK que reintentaba silenciosamente una solicitud muerta tres veces.

Un script de la stdlib, scripts/ci_audit.py en la carpeta de este skill, realiza las mediciones. Tú lees su salida, decides qué vale la pena arreglar y lo envías.

python3 <skill-dir>/scripts/ci_audit.py inventory <owner>              # qué repos ejecutan Actions, privados vs públicos
python3 <skill-dir>/scripts/ci_audit.py month <owner/repo>             # minutos facturables por workflow, 30 días
python3 <skill-dir>/scripts/ci_audit.py jobs <owner/repo> --runs 150   # cola / configuración / ejecución por trabajo
python3 <skill-dir>/scripts/ci_audit.py steps <owner/repo> <run-id>    # segundos por paso para una ejecución
python3 <skill-dir>/scripts/ci_audit.py schedules <owner/repo>         # cada cron como ejecuciones por mes

Requiere que la CLI de GitHub (gh) esté autenticada. month y jobs hacen una llamada a la API por ejecución, así que un repositorio con mucha actividad puede tardar uno o dos minutos. Ejecútalos en segundo plano.

Paso 0 — Alcance y reglas

Antes de medir, acuerda con el usuario:

• Qué propietarios y repos. Un solo repositorio, o todo lo que se haya subido en los últimos 60 días.
• Repos fuera de límites. Alguien más (un compañero, otro agente) está trabajando allí. Esos reciben un issue con números, nunca una rama subida.
• Dónde van las fusiones. La rama de integración (development, por ejemplo) por defecto. Hacer un release a la rama predeterminada es un "sí" aparte, pero los crons y las correcciones programadas solo surten efecto después de eso (Paso 6).
• Qué está fuera del alcance: reducir la cobertura de pruebas, runners de pago, cambiar de proveedor de CI. Recomiéndalos con números; no los hagas.

Lee references/gotchas.md ahora.

Paso 1 — Inventario y dinero

1. ci_audit.py inventory <owner> para cada propietario. Anota repos privados vs públicos: solo los privados cuestan dinero, pero el tiempo de espera de cada repo importa cuando los agentes se bloquean esperando al CI.
2. Para una organización, obtén la facturación real: gh api "/organizations/<org>/settings/billing/usage?year=YYYY&month=M". Para una cuenta personal, usa ci_audit.py month en cada repositorio privado y compara el total con los minutos incluidos en el plan.
3. Anota los 5 repos principales por minutos facturables. Ahí es donde se va el tiempo.

Paso 2 — Rotos antes que lentos

Para cada repositorio con workflows programados:

• Revisa las últimas 10 ejecuciones programadas por workflow. Cualquier workflow que falle siempre es el primer hallazgo, independientemente de su costo. Lee sus registros (gh api repos/O/R/actions/runs/<id>/logs > logs.zip).
• Ejecuta actionlint en .github/workflows/. Un archivo que GitHub no puede analizar nunca ejecutará su programación.

Espera errores en capas. Consulta references/fixes.md §1.

Paso 3 — Programaciones

ci_audit.py schedules <repo> en cada repositorio con crons. Multiplica las ejecuciones/mes por los minutos facturados por ejecución (de jobs). Señala:

• Trabajos cortos con programaciones ajustadas (una comprobación de 30 segundos cada hora son 730 min facturables/mes).
• Varios crons en el mismo minuto que golpean la misma API con límite de tasa.
• Crons mensuales que hacen una ejecución enorme. Divide el trabajo entre noches.

Paso 4 — Desglose por trabajo

Para los repos principales: ci_audit.py jobs <repo> --runs 150, luego steps en una ejecución verde reciente de cada trabajo costoso. Clasifica el tiempo de cada trabajo:

Categoría	¿A qué apunta?
Cola alta	Contención de runners o grupos de concurrencia. Por lo general no se puede arreglar barato; anótalo.
Configuración alta	Instalación de dependencias y caché (references/fixes.md §3–4).
Ejecución alta, pruebas de la app	Tiempo real de pruebas. Déjalo a menos que un paso sea claramente redundante.
Ejecución alta, pipeline de datos	Instrumenta las fases y arregla el código, no el CI (references/fixes.md §6).
Fallos > 5%	Pruebas inestables o pipelines rotos (references/fixes.md §1, §7).

Paso 5 — Informe y selección

Escribe una tabla, ordenada por minutos estimados ahorrados al mes:

Repo	Hallazgo	Evidencia	Corrección	Est. ahorro/mes	Riesgo

Incluye hallazgos que no vas a corregir (repos fuera de límites, decisiones del propietario como frecuencia de cron o paralelismo) con los números que el propietario necesita para decidir. Muéstraselo al usuario y obtén autorización sobre qué filas enviar. Archiva como ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/ci-audit/archive/<YYYY-MM-DD>-<scope>.md.

Paso 6 — Ronda de correcciones

Un repo, un trabajador. En hosts que soporten subagentes, ejecuta los repos en paralelo con la misma consigna: clon nuevo, issue primero, rama nombrada según el issue, commits pequeños, números de antes/después en el cuerpo del PR.

Para cada corrección:

1. Abre un issue con la medición.
2. Haz el cambio en una rama. Verifica lint y ejecuta pruebas localmente, confirmando por código de salida.
3. Demuéstralo: sube, luego vuelve a ejecutar el CI del PR para que la caché esté caliente, y compara con una línea base de varias ejecuciones antiguas. Para correcciones de pipeline, ejecuta el workflow desde la rama con un límite pequeño.
4. Si el cambio no ayudó (ocurre, por ejemplo, con cachés de Playwright), cierra el PR con los números. Eso es un resultado, no un fracaso.
5. Fusiona en la rama de integración después de la revisión y las comprobaciones verdes.
6. Para cualquier cosa programada, abre el PR de release a la rama predeterminada una vez que el usuario esté de acuerdo. Hasta entonces, nada cambia en producción.

Paso 7 — Verificar y registrar

• Después de la siguiente ejecución programada, lee sus tiempos y registros. Confirma que la corrección se mantuvo en producción, no solo en la rama.
• Añade los resultados al archivo de archivo: antes/después por repo, qué se cerró sin fusionar y nuevos gotchas.
• Sugiere repetir la auditoría mensualmente, o cada vez que el CI se sienta lento. Un recordatorio recurrente (loopify) funciona bien.

Se compone con

• loopify — programar una reauditoría mensual o una verificación a la mañana siguiente de la primera ejecución programada.
• castmate — obtener la revisión de un segundo modelo sobre un cambio de workflow arriesgado.
• unstuck — cuando una corrección que debería funcionar mide más lento, antes de rendirse.
• project-manager — hacer seguimiento de las decisiones del propietario (frecuencia de cron, runners de pago) que la auditoría descubrió pero no implementó.

Notas sobre calidad

• Roto supera a lento. Siempre verifica los workflows programados fallidos antes de medir tiempos. Un pipeline diario fallando durante seis meses es una pérdida mayor que cualquier caché.
• Números en caliente o no hay afirmación. Nunca reportes una aceleración de una sola ejecución en frío. Vuelve a ejecutar, establece una línea base con varias ejecuciones antiguas y muestra ambos números en el PR.
• Minutos facturables, no segundos. El redondeo por trabajo significa que menos trabajos más completos superan a muchos pequeños en repos privados. Paralelizar es una decisión de velocidad con un costo, no una ganancia gratuita.
• Misma cobertura, siempre. El conteo de pruebas antes y después va en el cuerpo del PR. Un conjunto de pruebas más rápido que ejecuta menos no es una corrección.
• Programado significa rama predeterminada. No des por terminada una corrección de cron o pipeline hasta que esté en la rama predeterminada y haya pasado una ejecución programada.
• Cierra experimentos fallidos con datos. Un PR que midió más lento se cierra con sus números, para que nadie vuelva a intentar la misma idea el próximo trimestre.
• Respeta las ramas de los demás. Los repos fuera de límites reciben issues, nunca subidas.