reyalka/astro

Analyser les logs GitHub Actions

Récupère et analyse les exécutions récentes de GitHub Actions pour un workflow donné. Examine les performances des agents/étapes, identifie le travail superflu et les erreurs, et produit un rapport avec des améliorations concrètes.

Entrée

Vous avez besoin :

• workflow (obligatoire) — Le nom du fichier de workflow ou son ID (ex. issue-triage.yml, deploy.yml).
• repo (optionnel) — Le dépôt GitHub au format PROPRIÉTAIRE/DÉPÔT. Par défaut : withastro/astro.
• count (optionnel) — Nombre d'exécutions complétées récentes à analyser. Par défaut : 5.

Étape 1 : Lister les exécutions récentes

Récupérez les exécutions complétées les plus récentes pour le workflow. Filtrez avec --status=completed :

gh run list --workflow=<workflow> -R <repo> --status=completed -L <count>

Présentez la liste pour vous orienter : IDs des exécutions, titres, statut (succès/échec) et durée. Choisissez les exécutions à analyser — privilégiez un mélange de succès et d'échecs si disponible, et préférez les exécutions qui ont réalisé le plus d'étapes (les exécutions longues tendent à traverser plus d'étapes, tandis que les plus courtes peuvent s'arrêter prématurément).

Étape 2 : Récupérer les logs

Pour chaque exécution que vous souhaitez analyser, enregistrez le log complet dans un fichier temporaire :

gh run view <run_id> -R <repo> --log > /tmp/actions-run-<run_id>.log

Étape 3 : Identifier les limites des étapes/compétences

Parcourez chaque fichier de log à la recherche de marqueurs indiquant où chaque étape ou compétence commence et se termine. Les marqueurs dépendent du workflow — cherchez des motifs comme :

• Marqueurs de compétence flue : [flue] skill("..."): starting / completed
• Marqueurs d'étape GitHub Actions : en-têtes de noms d'étape dans la sortie du log
• Marqueurs personnalisés : tout délimiteur START/END ou similaire utilisé par le workflow

grep -n "skill(\|step\|START\|END\|starting\|completed" /tmp/actions-run-<run_id>.log | head -50

À partir de cela, déterminez quelles plages de lignes correspondent à chaque étape/compétence. Trouvez également les marqueurs de résultat :

grep -n "RESULT_START\|RESULT_END\|extractResult" /tmp/actions-run-<run_id>.log

Remarque : certains fichiers de log peuvent contenir des octets nuls/binaires. Utilisez grep -a si nécessaire.

Étape 4 : Analyser chaque étape (utiliser des sous-agents)

Pour chaque étape/compétence qui a été exécutée, lancez un sous-agent pour analyser la section correspondante du log. Ceci est essentiel pour éviter de polluer votre contexte avec des milliers de lignes de log.

Pour chaque sous-agent, fournissez :

1. Le chemin du fichier de log et la plage de lignes pour cette étape
2. Si des fichiers d'instructions de compétence existent pour le workflow, demandez au sous-agent de les lire d'abord pour obtenir du contexte
3. Le titre/contexte de l'exécution afin que le sous-agent comprenne ce qui a été fait
4. Les critères d'analyse ci-dessous

Critères d'analyse

Demandez à chaque sous-agent d'évaluer :

1. Exactitude — Le résultat/verdict final de l'étape était-il correct ?
2. Efficacité — Combien de temps cela a-t-il pris ? Quelle serait une base de référence raisonnable ? Où le temps a-t-il été perdu ?
3. Erreurs — Appels d'outils incorrects, commandes échouées relancées sans modification, reconstructions inutiles, etc.
4. Conformité aux instructions — Si des instructions de compétence existent, l'agent les a-t-il suivies ? Où s'en est-il écarté ?
5. Débordement de périmètre — L'agent a-t-il effectué un travail qui appartient à une autre étape ?
6. Suggestions — Modifications spécifiques et concrètes qui empêcheraient les problèmes rencontrés.

Demandez à chaque sous-agent de retourner une réponse structurée avec : Résumé, Analyse temporelle, Problèmes identifiés (avec estimation du temps perdu pour chacun), et Suggestions d'amélioration.

Étape 5 : Consolider le rapport

Une fois que tous les sous-agents ont répondu, synthétisez leurs résultats en un seul rapport. Structurez-le comme suit :

Tableau récapitulatif par exécution

Pour chaque exécution analysée, incluez un tableau :

Étape/Compétence	Temps	Résultat	Temps perdu	Problème principal

Tendances transversales

Identifiez les problèmes qui sont apparus dans plusieurs exécutions ou plusieurs étapes. Ce sont les améliorations les plus précieuses. Cherchez des motifs courants comme :

• Abus de TodoWrite — L'agent perd du temps à gérer la liste de tâches lors d'exécutions automatisées
• Échecs de gestion de serveur — Conflits de ports, arrêts de processus échoués, fichiers de log obsolètes
• Mauvaise utilisation d'outils — Utiliser curl au lieu de gh, jq introuvable, etc.
• Débordement de périmètre — Une étape effectue un travail qui appartient à une autre
• Reconstructions inutiles — Construire plusieurs fois des paquets sans changements
• Délais d'attente des tests — Exécution de tests E2E/Playwright lents qui expirent
• Violations des instructions — L'agent fait quelque chose que les instructions interdisent explicitement
• Travail redondant — Relecture de fichiers, relance de recherches, réinstallation de dépendances

Recommandations priorisées

Classez vos suggestions d'amélioration par estimation du temps économisé sur toutes les exécutions. Pour chaque recommandation :

1. Quoi changer — Quel(s) fichier(s) modifier et quoi ajouter/modifier
2. Pourquoi — Quel problème cela adresse, avec des preuves issues des exécutions
3. Impact estimé — Combien de temps cela permettrait d'économiser par exécution

Sortie

Présentez le rapport consolidé complet. NE modifiez AUCUN fichier de workflow ou de compétence — rapportez seulement les résultats et les recommandations. L'utilisateur décidera quels changements appliquer.