gha-doctor

gha-doctor es una herramienta de línea de comandos que diagnostica flaky jobs, minutos desperdiciados, pasos lentos, problemas de caché y antipatrones de workflow en un solo comando y con cero configuración. El README lo posiciona junto a actionlint (corrección) y zizmor (seguridad) como el que cubre velocidad, costo y fiabilidad. Lee .github/workflows para comprobaciones estáticas y usa GITHUB_TOKEN o autenticación gh existente para análisis del historial de ejecución; un modo solo-lint funciona sin conexión y sin autenticación. Una bandera --repo owner/name obtiene los archivos de workflow y historial de ejecución de otro repositorio a través de la API, por lo que no necesitan clonarse, y --org ejecuta triaje de flota a través de una organización o usuario. El análisis estático se organiza en 21 reglas documentadas (D001 a D021) con severidades y números de línea que señalan la ubicación exacta del YAML. Cubren cosas como falta de concurrency con cancel-in-progress en workflows de pull-request, jobs sin timeout-minutes, setup-node/setup-python/setup-java sin la entrada built-in cache, checkouts full-history, crons más frecuentes que cada 15 minutos, runners macOS y Windows en cada push, docker build-push sin cache-from, actions/cache sin restore-keys, continue-on-error a nivel de job, retención predeterminada de artifacts, matrices grandes, npm install en vez de npm ci, triggers dobles unscoped push plus pull_request, cron en minuto 0, etiquetas de runner apagadas o retiradas y versiones de action, falta de actualizaciones automáticas de pin de actions, comandos de workflow depreciados, runtimes de Node depreciados en actions publicadas, y workflows programados sin protección de repositorio. Los hallazgos pueden silenciarse en línea con un comentario en la línea marcada o globalmente con --disable, y cada regla puede explicarse sin conexión con --explain. El análisis del historial de ejecución detecta flaky jobs buscando jobs que fallaron y pasaron en el mismo commit, reporta tasa de éxito por workflow, duraciones p50 y p95, tiempo de cola y costo, identifica pasos más lentos y minutos desperdiciados, y puede medir tasas de hit/miss de caché y nombrar tests flaky desde logs de job. Todo lo medido se consolida en una puntuación de salud itemizada de 0 a 100 que puede escribirse como badge SVG. Los formatos de salida incluyen texto plano, JSON legible por máquina con JSON Schemas publicados, Markdown, SARIF 2.1.0, workflow commands de anotación en línea, y un reporte HTML autocontenido con gráficos integrados. Un modo auto-fix aplica ediciones quirúrgicas por línea para las reglas corregibles, con un modo diff separado para previsualizar cambios sin escribir. Un archivo de configuración del repositorio en .gha-doctor.yml o .github/gha-doctor.yml define políticas como reglas deshabilitadas, tamaño de muestra del historial, muestreo de logs y umbrales de fallo; las banderas de CLI explícitas toman precedencia y una bandera no-config la ignora. El exit code 2 señala warnings para que la herramienta pueda hacer gate CI, con gating de severidad configurable y umbral mínimo de puntuación de salud. El proyecto también se entrega como una composite GitHub Action que instala el binario de release y soporta inputs para args, version, token, job summary, comentarios sticky de pull-request, baseline diffing contra una base branch, y failure thresholds; las anotaciones en línea están activas por defecto. GitHub Enterprise Server es compatible a través de la variable GH_HOST. Un modo de servidor stdio Model Context Protocol expone seis herramientas solo-lectura (analyze_repo, lint_repo, preview_fixes, run_deep_dive, org_overview, explain_rule) para que clientes MCP consulten la salud de CI; el servidor está listado en el official MCP Registry y también puede ejecutarse desde la imagen del container. Las opciones de instalación incluyen una extensión gh CLI, Homebrew, Scoop, una imagen Docker multi-arch distroless, go install, aqua, mise/ubi, asdf, binarios de release, paquetes deb/rpm/apk, shell completions y pre-commit hooks. Un playground en navegador ejecuta el linter y sus auto-fixes client-side vía WebAssembly. El README indica que el proyecto está construido y mantenido por un agente de IA y que la herramienta solo lee desde repositorios; el uso de private-repo necesita permisos de Actions read y Contents read.