gha-doctor

gha-doctor est un outil en ligne de commande qui diagnostique les workflows GitHub Actions pour les jobs instables, les minutes gaspillées, les étapes lentes, les problèmes de cache et les anti-motifs de workflow en une seule commande et sans configuration. Le README le positionne aux côtés d'actionlint (correction) et zizmor (sécurité) comme couverture de la vitesse, des coûts et de la fiabilité. Il lit .github/workflows pour les vérifications statiques et utilise un GITHUB_TOKEN existant ou l'authentification gh CLI pour l'analyse de l'historique des exécutions ; un mode lint-only fonctionne hors ligne sans authentification. Un indicateur --repo owner/name récupère les fichiers de workflow et l'historique d'exécution d'un autre dépôt via l'API, donc les dépôts n'ont pas besoin d'être clonés, et --org exécute un triage de flotteau à travers une organisation ou un utilisateur. L'analyse statique est organisée en 21 règles documentées (D001 à D021) avec des sévérités et des numéros de ligne pointant vers l'emplacement exact du YAML. Elles couvrent des choses telles que l'absence de concurrence avec cancel-in-progress sur les workflows de pull-request, les jobs sans timeout-minutes, setup-node/setup-python/setup-java sans l'entrée cache intégrée, les checkouts en historique complet, les crons plus fréquents que toutes les 15 minutes, les runners macOS et Windows à chaque push, docker build-push sans cache-from, actions/cache sans restore-keys, le continue-on-error au niveau du job, la rétention par défaut des artefacts, les matrices volumineuses, npm install au lieu de npm ci, les doubles triggers push plus pull_request non qualifiés, le cron à la minute 0, les libellés de runners désactivés ou retirés et les versions d'actions, les mises à jour automatisées manquantes des pins d'actions, les commandes de workflow dépréciées, les runtimes Node dépréciés dans les actions publiées, et les workflows planifiés sans garde de dépôt. Les résultats peuvent être silencés en ligne avec un commentaire sur la ligne signalée ou globalement avec --disable, et chaque règle peut être expliquée hors ligne avec --explain. L'analyse de l'historique des exécutions détecte les jobs instables en cherchant les jobs qui ont à la fois échoué et réussi sur le même commit, rapporte le taux de succès par workflow, les durées p50 et p95, le temps d'attente et le coût, identifie les étapes les plus lentes et les minutes gaspillées, et peut mesurer les taux de hit et miss du cache ainsi que nommer les tests instables depuis les logs de job. Tout ce qui est mesuré s'agrège en un score de santé individualisé de 0 à 100 qui peut être écrit sous forme de badge SVG. Les formats de sortie incluent texte brut, JSON lisible-machine avec des JSON Schemas publiés, Markdown, SARIF 2.1.0, commandes de workflow d'annotation inline, et un rapport HTML auto-contenu avec graphiques intégrés. Un mode auto-fix applique des modifications de lignes chirurgicales pour les règles réparables, avec un mode diff séparé pour prévisualiser les changements sans écrire. Un fichier de configuration de dépôt dans .gha-doctor.yml ou .github/gha-doctor.yml définit la politique telle que les règles désactivées, la taille de l'échantillon d'historique, l'échantillonnage des logs et les seuils d'échec ; les indicateurs CLI explicites prévalent et un indicateur no-config l'ignore. Le code de sortie 2 signale les avertissements afin que l'outil puisse verrouiller le CI, avec un verrouillage de sévérité configurable et un seuil minimum de score de santé. Le projet est également livré en tant qu'Action composite GitHub qui installe le binaire release et prend en charge des entrées pour les args, la version, le token, le résumé de job, les commentaires sticky sur les pull-requests, le diff de base contre une branche de base, et les seuils d'échec ; les annotations inline sont activées par défaut. GitHub Enterprise Server est pris en charge via la variable GH_HOST. Un mode serveur stdio Model Context Protocol expose six outils en lecture seule (analyze_repo, lint_repo, preview_fixes, run_deep_dive, org_overview, explain_rule) pour que les clients MCP puissent interroger la santé du CI ; le serveur est répertorié dans le MCP Registry officiel et peut aussi s'exécuter depuis l'image conteneur. Les options d'installation incluent une extension gh CLI, Homebrew, Scoop, une image Docker multi-arch distroless, go install, aqua, mise/ubi, asdf, des binaires release, des paquets deb/rpm/apk, des complétions de shell et des hooks pre-commit. Un terrain de jeu navigateur exécute le linter et ses auto-fixes côté client via WebAssembly. Le README indique que le projet est construit et maintenu par un agent IA et que l'outil ne lit jamais que depuis les dépôts ; l'utilisation de dépôts privés nécessite les autorisations Actions read et Contents read.