Efficacité GitHub Actions

Utilisez cette compétence comme point d'entrée léger pour les travaux d'efficacité GitHub Actions. Inspectez le repo, identifiez la source de gaspillage, et chargez uniquement le matériel de référence nécessaire pour la tâche actuelle.

Si aucun workflow n'existe encore, chargez references/actions.md et définissez une baseline avant de procéder aux étapes ci-dessous.

Si l'accès shell ou à la CLI gh n'est pas disponible : demandez à l'utilisateur de coller le contenu de .github/workflows/ et la sortie de gh run list --limit 10. Si seulement des fichiers partiels sont fournis, notez-le : « Audit basé sur les fichiers fournis uniquement ; certaines analyses peuvent être incomplètes. » Commencez les réponses à partir de fichiers seuls par : « Analyse statique uniquement (non confirmée par des exécutions en direct). »

Utilisez cette compétence quand

• L'utilisateur veut réduire le runtime GitHub Actions, le coût CI, ou les exécutions de workflow gaspillées.
• Le repo a des workflows existants dans .github/workflows/ ou des questions de configuration GitHub Actions explicites.
• L'utilisateur demande de la mise en cache, de la concurrence, des filtres de chemin, une réduction de matrice, l'optimisation des jobs, ou des correctifs spécifiques au workflow.
• L'utilisateur a besoin d'aide pour créer un nouveau workflow GitHub Actions ou une baseline CI à partir de zéro.

Chargez seulement ce dont vous avez besoin

• references/actions.md — audits, gating de jobs, réduction de matrice, validation en direct, et correctifs spécifiques au workflow.
• references/reporting.md — quand l'utilisateur demande un rapport d'efficacité avant/après.
• references/patterns.md — exemples YAML complets quand les commandes d'audit inline ne suffisent pas.

Flux de travail principal

1. Mesurez d'abord

rg -n "on:|concurrency:|paths:|paths-ignore:|strategy:|matrix:|cache:" .github/workflows
gh run list --limit 10
run_id=$(gh run list --limit 1 --json databaseId --jq '.[0].databaseId')
gh run view "$run_id" --log-failed

Cherchez : caches de dépendances manquants, annulation concurrency manquante, déclencheurs trop larges, couverture de workflow dupliquée, et jobs coûteux qui s'exécutent à chaque changement indépendamment de la portée.

2. Appliquez des garde-fous

Vérifiez chaque correctif proposé par rapport à ces règles avant de le recommander :

1. Ne masque pas la validation requise — supprimez tout correctif qui supprime les contrôles de release, schéma, migration, ou de bibliothèque partagée.
2. Ne réduit pas le parallélisme sans justification — supprimez sauf si l'utilisateur a priorisé le coût sur la latence et le nouveau chemin critique reste dans 1,25× l'original.
3. Préserve seulement les legs de matrice documentés — supprimez les legs de matrice sans engagement de version ou de plateforme explicite.
4. Les jobs d'écriture utilisent des déclencheurs opt-in — signalez (ne supprimez pas) les jobs de formateur ou bot qui s'exécutent automatiquement ; recommandez un déclencheur opt-in à la place.
5. Les changements de repo restent séparés des paramètres org — divisez tout correctif qui mélange du YAML éditable par repo avec des paramètres au niveau org ou du compte GitHub en deux recommandations distinctes.

3. Sélectionnez les 3 meilleurs correctifs

Parmi les six candidats ci-dessous, gardez seulement ceux supportés par des preuves d'audit de l'étape 1 et passant tous les garde-fous de l'étape 2. Classez les survivants par minutes CI quotidiennes estimées économisées (économies par exécution × exécutions par jour). Sélectionnez tous les candidats qui répondent aux deux critères, jusqu'à un maximum de 3.

1. Ajouter la mise en cache de dépendances avec clés basées sur le fichier de verrouillage
2. Ajouter ou corriger l'annulation concurrency
3. Supprimer la couverture de workflow dupliquée avant de fusionner les jobs
4. Affiner les déclencheurs de workflow ou de job en toute sécurité
5. Réduire la largeur de la matrice pour correspondre au risque et au type d'événement
6. Paralléliser les jobs indépendants sur le chemin critique

4. Vérifiez

• Si l'accès à la CLI gh est disponible, validez le gating de chemin et l'annulation de concurrence avec un test de push en direct sur une branche non protégée.
• Si la validation en direct n'est pas possible, déclarez-le explicitement dans la sortie.
• Traitez le comportement inattendu en direct comme un vrai bug même quand le YAML semble correct.

Sortie requise

1. Sources de gaspillage — principaux coût ou moteurs de latence trouvés à l'étape 1
2. Correctifs proposés — 3 meilleurs (ou tous restants) avec preuves d'audit à l'appui
3. Validation — ce qui a été prouvé en direct, ce qui a été vérifié localement seulement, et tout risque restant
4. Impact — économies attendues vs. économies mesurées ; séparez le temps wall-clock PR du temps de runner total

Références

• references/actions.md
• references/reporting.md
• references/patterns.md
• references/review-rubric.md — chargez quand vous passez en revue les travaux d'efficacité achevés