coreyhaines31/ci-audit

/ci-audit — Trouver et corriger le temps perdu dans GitHub Actions

Mesurez d'abord, puis corrigez les quelques choses qui comptent vraiment. Dans les audits réels, la plus grosse perte était rarement une suite de tests lente. C'était un pipeline planifié qui échouait chaque jour depuis des mois, un cron de 30 secondes toutes les heures facturé comme 730 minutes par mois, ou un SDK qui réessayait silencieusement une requête morte trois fois.

Un script stdlib, scripts/ci_audit.py dans le dossier de cette compétence, effectue les mesures. Vous lisez sa sortie, décidez ce qui vaut la peine d'être corrigé, et le livrez.

python3 <skill-dir>/scripts/ci_audit.py inventory <owner>              # quels dépôts exécutent Actions, privés vs publics
python3 <skill-dir>/scripts/ci_audit.py month <owner/repo>             # minutes facturables par workflow, 30 jours
python3 <skill-dir>/scripts/ci_audit.py jobs <owner/repo> --runs 150   # file d'attente / démarrage / exécution par job
python3 <skill-dir>/scripts/ci_audit.py steps <owner/repo> <run-id>    # secondes par étape pour une exécution
python3 <skill-dir>/scripts/ci_audit.py schedules <owner/repo>         # chaque cron avec son nombre d'exécutions par mois

Il nécessite que la CLI GitHub (gh) soit connectée. month et jobs font un appel API par exécution, donc un dépôt actif prend une minute ou deux. Exécutez-les en arrière-plan.

Étape 0 — Périmètre et règles

Avant de mesurer, fixez avec l'utilisateur :

• Quels propriétaires et dépôts. Un dépôt, ou tout ce qui a été poussé au cours des 60 derniers jours.
• Dépôts interdits. Un coéquipier (ou un autre agent) est en pleine fonctionnalité. Ceux-ci reçoivent un issue avec des chiffres, jamais une branche poussée.
• Où vont les fusions. La branche d'intégration (development, par exemple) par défaut. Livrer sur la branche par défaut est un « oui » séparé, mais les crons et les correctifs planifiés ne prennent effet qu'après (Étape 6).
• Ce qui est hors du périmètre : réduire la couverture de tests, les exécuteurs payants, changer de fournisseur CI. Recommandez-les avec des chiffres ; ne les faites pas.

Lisez references/gotchas.md maintenant.

Étape 1 — Inventaire et argent

1. ci_audit.py inventory <owner> pour chaque propriétaire. Notez privé vs public : seuls les dépôts privés coûtent de l'argent, mais le temps d'attente de chaque dépôt compte quand les agents bloquent sur la CI.
2. Pour une organisation, récupérez la facturation réelle : gh api "/organizations/<org>/settings/billing/usage?year=YYYY&month=M". Pour un compte personnel, utilisez ci_audit.py month sur chaque dépôt privé et comparez le total avec les minutes incluses du plan.
3. Notez les 5 principaux dépôts par minutes facturables. C'est là que le temps passe.

Étape 2 — Cassé avant lent

Pour chaque dépôt avec des workflows planifiés :

• Vérifiez les 10 dernières exécutions planifiées par workflow. Tout workflow qui échoue systématiquement est la première constatation, quel que soit son coût. Lisez ses logs (gh api repos/O/R/actions/runs/<id>/logs > logs.zip).
• Exécutez actionlint sur .github/workflows/. Un fichier que GitHub ne peut pas analyser n'exécute jamais son planning.

Attendez-vous à des erreurs en cascade. Voir references/fixes.md §1.

Étape 3 — Plannings

ci_audit.py schedules <repo> sur chaque dépôt avec des crons. Multipliez les exécutions/mois par les minutes facturables par exécution (depuis jobs). Signalez :

• Les jobs courts avec des plannings serrés (une vérification de 30 secondes toutes les heures représente 730 minutes facturables/mois).
• Plusieurs crons à la même minute qui frappent la même API limitée.
• Les crons mensuels qui font une seule énorme exécution. Répartissez le travail sur plusieurs nuits.

Étape 4 — Analyse par job

Pour les principaux dépôts : ci_audit.py jobs <repo> --runs 150, puis steps sur une exécution récente réussie de chaque job coûteux. Classez le temps de chaque job :

Catégorie	Ce qu'elle indique
File d'attente élevée	Contention d'exécuteurs ou groupes de concurrence. Généralement pas corrigeable à moindre coût ; notez-le.
Démarrage élevé	Installation des dépendances et mise en cache (references/fixes.md §3–4).
Exécution élevée, tests app	Temps de test réel. Laissez-le sauf si une étape est clairement redondante.
Exécution élevée, pipeline de données	Instrumentez les phases et corrigez le code, pas la CI (references/fixes.md §6).
Échecs > 5%	Tests instables ou pipelines cassés (references/fixes.md §1, §7).

Étape 5 — Rapport et choix

Rédigez un tableau, trié par minutes estimées économisées par mois :

Dépôt	Constatation	Preuve	Correctif	Est. économisées/mois	Risque

Incluez les constatations que vous ne corrigerez pas (dépôts interdits, décisions du propriétaire comme la fréquence des crons ou le parallélisme) avec les chiffres dont le propriétaire a besoin pour décider. Montrez-le à l'utilisateur et obtenez un accord sur les lignes à livrer. Archivez-le sous ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/ci-audit/archive/<YYYY-MM-DD>-<scope>.md.

Étape 6 — Passage de correctifs

Un dépôt, un travailleur. Sur les hôtes qui supportent les sous-agents, exécutez les dépôts en parallèle avec la même consigne : clone frais, issue d'abord, branche nommée d'après l'issue, petits commits, chiffres avant/après dans le corps de la PR.

Pour chaque correctif :

1. Ouvrez un issue avec la mesure.
2. Faites la modification sur une branche. Lint et exécutez les tests localement, en confirmant par le code de sortie.
3. Prouvez-le : poussez, puis réexécutez la CI de la PR pour que le cache soit chaud, et comparez avec une base de référence de plusieurs anciennes exécutions. Pour les correctifs de pipeline, déclenchez le workflow depuis la branche avec une petite limite.
4. Si le changement n'a pas aidé (ça arrive, par exemple les caches Playwright), fermez la PR avec les chiffres. C'est un résultat, pas un échec.
5. Fusionnez dans la branche d'intégration après review et validation verte.
6. Pour tout ce qui est planifié, ouvrez la PR de livraison vers la branche par défaut une fois que l'utilisateur a donné son accord. Jusque-là, rien ne change en production.

Étape 7 — Vérifier et journaliser

• Après la prochaine exécution planifiée, lisez ses timings et logs. Confirmez que le correctif a tenu en production, pas seulement sur la branche.
• Ajoutez les résultats au fichier d'archive : avant/après par dépôt, ce qui a été fermé sans fusion, et nouveaux pièges.
• Suggérez de réexécuter l'audit mensuellement, ou dès que la CI semble lente. Un rappel récurrent (loopify) fonctionne bien.

Se compose avec

• loopify — planifier un réaudit mensuel ou une vérification le lendemain matin de la première exécution planifiée.
• castmate — obtenir une relecture d'un second modèle sur un changement de workflow risqué.
• unstuck — quand un correctif qui devrait fonctionner se mesure plus lent, avant d'abandonner.
• project-manager — suivre les décisions du propriétaire (fréquence des crons, exécuteurs payants) que l'audit a révélées mais n'a pas mises en œuvre.

Notes sur la qualité

• Cassé avant lent. Vérifiez toujours les workflows planifiés qui échouent avant de chronométrer quoi que ce soit. Un pipeline quotidien qui échoue depuis six mois est une perte plus importante que n'importe quel cache.
• Chiffres à chaud ou pas de revendication. Ne rapportez jamais une accélération depuis une seule exécution à froid. Réexécutez, basez-vous sur plusieurs anciennes exécutions, et mentionnez les deux chiffres dans la PR.
• Minutes facturables, pas secondes. L'arrondi par job signifie que moins de jobs, plus complets, battent plusieurs petits jobs sur les dépôts privés. Paralléliser est une décision de vitesse avec un coût, pas un gain gratuit.
• Même couverture à chaque fois. Le nombre de tests avant et après va dans le corps de la PR. Une suite plus rapide qui exécute moins de tests n'est pas un correctif.
• Planifié signifie branche par défaut. Ne considérez pas un correctif de cron ou de pipeline comme terminé tant qu'il n'est pas sur la branche par défaut et qu'une exécution planifiée a réussi.
• Fermez les expériences échouées avec des données. Une PR qui s'est mesurée plus lente est fermée avec ses chiffres, afin que personne ne réessaie la même idée au prochain trimestre.
• Respectez les branches des autres. Les dépôts interdits reçoivent des issues, jamais de poussées.