Rapport d'Échec de Pipeline

Entrée : pipeline GitLab model-coverage AutoDeploy le plus récent, ou un ID de pipeline amont/aval ou une URL de pipeline spécifique. Exigence d'authentification : l'utilisateur doit exporter un token GitLab dans GITLAB_TOKEN avant que cette compétence puisse interroger les pipelines, les jobs ou les traces. Sortie : commencez par demander à l'utilisateur quel format de sortie est préféré. Par défaut, rapportez dans le chat. Les sorties alternatives sont un rapport Markdown (md) et un CSV par défaut (csv). La compétence produit toujours un rapport d'échec catégorisé plus au maximum une PR par bucket de cause racine actuelle, et quand une PR n'est pas justifiée mais que le bucket mérite encore d'être suivi, créez un problème pour ce bucket.

Règle Fondamentale

Cette compétence doit être autonome. Résolvez les pipelines, les jobs échoués et les logs bruts directement à partir des APIs GitLab et des traces de jobs. Ne dépendez pas du code autodeploy-dashboard, des scripts, des CSV ou de sa logique de catégorisation héritée. Cette compétence détient les règles de catégorisation, les règles d'exclusion, la décision de propriété du repo et le comportement une-PR-par-bucket.

Avant tout appel API GitLab, exigez que GITLAB_TOKEN soit défini dans l'environnement. S'il manque, arrêtez immédiatement et dites à l'utilisateur : Set GITLAB_TOKEN to a GitLab personal access token and rerun this skill.

Avant de faire l'analyse principale, demandez à l'utilisateur quelle sortie est préférée :

chat (par défaut)
md
csv

Si l'utilisateur ne précise pas, par défaut à chat.

Phase 0 — Résoudre l'Étendue

L'étendue par défaut est model-coverage. Ne basculez pas silencieusement vers les pipelines de benchmark.
Si l'utilisateur demande explicitement d'analyser un pipeline de benchmark, arrêtez et dites-lui que cette compétence ne prend pas en charge les pipelines de benchmark.
Si l'utilisateur donne un ID de pipeline ou une URL de pipeline GitLab, utilisez-le.
Traitez un pipeline fourni par l'utilisateur comme potentiellement soit :
- un pipeline AutoDeploy amont dans ftp/infra/autodeploy-dashboard
- un pipeline déclenché aval dans dl/jet/ci
Si le pipeline de départ est amont, suivez la chaîne de bridge échouée jusqu'à atteindre le premier pipeline aval avec des jobs model-coverage terminaux.
Sinon, résolvez le pipeline AutoDeploy amont le plus récent qui a exécuté model-coverage, puis suivez la même chaîne de bridge jusqu'au pipeline terminal.
Si GITLAB_TOKEN manque, arrêtez immédiatement et dites à l'utilisateur exactement comment corriger : Set GITLAB_TOKEN to a GitLab personal access token and rerun this skill.

Règles de Résolution de Pipeline

Utilisez cet ordre de résolution :

Identifiez si le pipeline fourni appartient au projet dashboard amont ou au projet aval dl/jet/ci.
S'il est amont, inspectez ses jobs de bridge et sélectionnez le chemin de déclenchement model-coverage échoué.
Si le pipeline suivant ne contient que des jobs de bridge, continuez à suivre la chaîne de déclenchement échouée.
Arrêtez au premier pipeline aval qui contient des jobs model-coverage terminaux échoués avec des traces.
Rapportez les deux :
- le pipeline de départ face à l'utilisateur
- le pipeline terminal qui contient les jobs échouant réels

N'analysez pas seulement l'échec du bridge si un pipeline aval plus profond contient les traces réelles du job.

Toutes les étapes GitLab API et de récupération de trace dans cette compétence doivent s'authentifier avec le token de GITLAB_TOKEN.

Phase 1 — Rassembler les Preuves d'Échec

Pour chaque job échoué, collectez :

ID du pipeline
ID du job et URL du job
URL du log brut
nom de la charge de travail
configuration du modèle ou du benchmark
premier extrait d'erreur causale du log brut

Collectez également :

ID du pipeline de départ
ID du pipeline terminal
si le job provenait d'un chemin aval suivi par bridge

Avant de proposer un correctif, lisez au moins un log brut représentatif pour chaque bucket provisoire. Ne comptez pas uniquement sur les labels hérités.

Règles de lecture de trace :

Dans les pipelines terminaux model-coverage, les jobs viennent souvent par triplets comme [1 logs_before], [2 <runner/stage>], [3 logs_after]. La charge de travail échouée primaire est généralement le job [2 ...]. Utilisez [1] et [3] uniquement comme preuve supplémentaire si nécessaire.
Si la trace se termine par des échecs de wrapper génériques tels que RuntimeError: Executor worker returned error, RuntimeError: Executor worker died during initialization, ou ERROR: Job failed: Process exited with status 1, continuez à scanner vers le haut et enregistrez plutôt l'exception antérieure spécifique au modèle, à l'export, au tokeniseur ou à l'environnement.
Préférez la première exception spécifique qui explique l'échec plutôt que les retombées ultérieures de la suppression de worker, du nettoyage Slurm ou du démarrage proxy.
Quand la charge de travail déverse sa configuration dans la trace, capturez la valeur résolue de model: et les hints de yaml_extra/runtime pertinents. Ils sont souvent utiles pour expliquer pourquoi un bucket est multimodal, spécifique à la taille mondiale ou utilisant un mode spécial.

Règles de Bucket Possédées par la Compétence

Chaque job échoué analysé doit finir exactement dans un bucket. Ne laissez pas les échecs dans une fourre-tout implicite comme other, misc ou untriaged dans le rapport final.

Ceci comprend les cas infra et externes. Ils ont toujours besoin de buckets explicites, par exemple :

infra/resource/oom
infra/runtime/timeout-or-freeze
infra/runtime/cancelled
infra/filesystem/hf-lock-permission
external/huggingface/access-forbidden
external/huggingface/missing-revision
external/huggingface/invalid-tokenizer-or-processor
external/env/missing-python-package
external/transformers/api-mismatch

Ne supposez pas que oom ou timeout-or-freeze sont infra uniquement. Dans les pipelines AutoDeploy, ils reflètent souvent des bugs réels TensorRT-LLM / AutoDeploy. Classez-les comme infra/... uniquement quand les preuves pointent vers du bruit de cluster ou un problème de ressource non-code. Sinon, catégorisez-les sous le repo/composant propriétaire réel.

Groupez les échecs ensemble uniquement quand tous les éléments suivants sont vrais :

ils pointent vers le même probable propriétaire de code et repo cible
ils partagent la même signature d'échec causale, comme le même symbole échoué, op, assertion, frame de pile ou chemin de config
ils semblent corrigibles par un changement de code cohérent
une PR peut raisonnablement expliquer pourquoi le même correctif couvre chaque job correspondant

Divisez les échecs dans des buckets différents quand n'importe lequel de ceux-ci est vrai :

la première erreur causale diffère même si la catégorie héritée correspond
le même symptôme provient de repos ou sous-systèmes différents
un échec est du bruit infrastructure et l'autre est un bug de code
les correctifs probables toucheraient des fichiers sans rapport ou nécessiteraient une validation différente
les preuves sont mitigées ou contradictoires

Quand incertain, divisez plutôt que de fusionner.

Si un job échoué ne correspond à aucun bucket existant, mettez-le dans son propre bucket d'un seul job. Ne le laissez pas sans catégorie.

Ce bucket d'un seul job doit toujours être étiqueté exactement comme l'un de :

actionable — probablement corrigible avec une PR
issue-only — vaut la peine d'être suivi, mais pas prêt pour une PR

N'utilisez pas un label skip PR. Si un bucket ne doit pas produire une PR, marquez-le issue-only quand il mérite toujours d'être suivi.

Les buckets comme OOM, timeout/freeze, cancelled ou les échecs d'accès Hugging Face doivent toujours apparaître explicitement dans le rapport. Si le mode d'échec partagé est assez clair pour être suivi, préférez issue-only.

Le rapport final doit rendre compte de tous les jobs échoués :

incluez le total de jobs échoués
incluez les comptages de buckets
assurez-vous que la somme de toutes les tailles de buckets égale le total des jobs échoués
rendez explicites les cas non appariés ou à faible confiance comme des buckets singleton plutôt que de les cacher

Utilisez cet ordre de priorité des preuves lors de la catégorisation :

premier frame de pile causale ou assertion
symbole, op, couche, clé de config ou script échoué explicite
extrait d'erreur répété proche du premier échec
formulation d'échec répétée dans les traces correspondantes
nommage de job et métadonnées de charge de travail uniquement comme bris égalité faible

Chaque bucket doit avoir :

un nom de bucket court sous la forme repo/component/failure-mode
un job représentatif
une liste de tous les jobs correspondants
une hypothèse de cause racine liée au code

Règles d'Exclusion

Ne créez pas une PR pour un bucket quand n'importe lequel de ceux-ci est vrai :

les échecs sont du bruit infrastructure pur comme timeout, préemption, annulation de cluster ou échec d'accès log sans preuve de code
les jobs ne partagent pas un correctif de code plausible
les preuves sont trop faibles pour pointer vers un chemin de code concret
le problème appartient à l'infrastructure externe ou à une dépendance externe en dehors des repos vérifiés
une PR ouverte semble déjà aborder le même bucket
la seule commonalité est un label de statut large ou une formulation superficielle

Si le pipeline de départ a échoué uniquement parce qu'un bridge a échoué, ne traitez pas le bridge comme son propre bucket actionnaire à moins que le pipeline terminal aval n'ait pas de jobs échouant ou pas de traces accessibles.

Les buckets infrastructure et externes doivent toujours être rapportés comme des buckets explicites. Ils devraient généralement être issue-only plutôt que promus à une PR à moins que les preuves pointent clairement vers un correctif détenu par le repo.

Les patterns issue-only courants vus dans les pipelines model-coverage AutoDeploy :

repos Hugging Face fermés ou interdits (403)
révisions/modèles Hugging Face manquants ou renommés (404)
packages Python optionnels manquants tels que timm, num2words, mamba_ssm, causal_conv1d ou dépendances runtime similaires
problèmes de permissions du système de fichiers sur les fichiers de verrouillage du cache Hugging Face
seulement des échecs de ressources clairement non-code après examen du log ; ne classez pas automatiquement CUDA OOM ou timeout/freeze comme infra sans vérifier une cause racine AutoDeploy

Règles de Propriété du Repo

Préférez TensorRT-LLM quand la cause racine est dans :

code de modèle AutoDeploy
runtime AutoDeploy ou transformations
tests, configs ou chemins d'exécution possédés par TensorRT-LLM
chemins de code surfacés par ad-debug-agent

Préférez autodeploy-dashboard quand la cause racine est dans :

scripts d'analyse d'échec
génération de charge de travail
résolution d'URL de job ou de log brut
lacunes d'orchestration ou de rapportage de pipeline dans le repo du pipeline AutoDeploy

N'ouvrez pas une PR quand le bucket appartient à l'infrastructure de cluster, au comportement du service GitLab ou à un autre système externe qui n'est pas possédé par les repos vérifiés.

Phase 2 — Valider Chaque Bucket

Pour chaque bucket :

Lisez le log du job représentatif et isolez le premier échec causale, pas la retombée aval.
Lisez le code, la config ou le script pertinents vers lesquels l'échec pointe.
Confirmez que la même hypothèse explique les autres jobs du bucket.
Si un traçage AutoDeploy plus profond est nécessaire, utilisez le workflow ad-debug-agent pour inspecter le chemin de code échouant avant d'éditer.
Si le log représentatif ne soutient pas réellement l'hypothèse du bucket, divisez ou rejetez le bucket.

Ne commencez pas à coder jusqu'à ce que le bucket ait les deux :

un extrait de log représentatif
une hypothèse au niveau du code

Phase 3 — Créer Au Maximum Un Correctif Par Bucket

Travaillez un bucket à la fois.

Pour un bucket actionnaire :

Choisissez le plus petit changement de code qui plausiblement corrige la cause racine partagée.
Préférez un correctif ciblé plutôt qu'un nettoyage large.
Vérifiez avec l'étape de test ou de validation la plus petite pertinente.
Si la validation suggère que le bucket contient réellement plusieurs causes racines, divisez avant d'ouvrir des PRs.
Créez une branche et une PR pour le bucket complet.

N'ouvrez jamais une PR par job échoué quand les jobs partagent le même correctif.

Phase 3b — Créer Un Problème Quand Aucune PR N'est Disponible

Si un bucket vaut la peine d'être suivi, mais que vous n'avez pas assez de confiance pour une PR, créez un problème pour ce bucket au lieu d'arrêter silencieusement.

Créez un problème quand tous les éléments suivants sont vrais :

le bucket a un mode d'échec partagé clair
les logs représentatifs fournissent assez de preuves pour expliquer le bucket
un problème peut clairement décrire le mode d'échec partagé
une PR n'est pas justifiée parce que le correctif est incertain, risqué, mitigé, sous-validé, externe ou infra-lié

Ne créez pas un problème quand n'importe lequel de ceux-ci est vrai :

les preuves sont trop faibles pour expliquer le mode d'échec du tout
un problème ou PR ouvert semble déjà couvrir le même bucket
le bucket est juste une restatement dupliquée d'un autre bucket

Les problèmes pour les buckets infra ou externes sont valides. Les exemples incluent :

infra/resource/oom
infra/runtime/timeout-or-freeze
infra/runtime/cancelled
external/huggingface/access-forbidden
external/huggingface/missing-revision
external/env/missing-python-package

Pour oom et timeout-or-freeze, préférez un bucket détenu par le repo au lieu si les traces suggèrent un problème AutoDeploy reproductible plutôt que du bruit infrastructure.

Lors de la création d'un problème dans TensorRT-LLM, utilisez les templates du repo dans .github/ISSUE_TEMPLATE/ plutôt que d'inventer un corps de problème personnalisé.

Pour les buckets d'échec de cette compétence, utilisez .github/ISSUE_TEMPLATE/06-bug-report.yml par défaut.
Utilisez un autre template uniquement si le bucket est clairement une demande de fonctionnalité ou une autre catégorie non-bug.

Remplissez le template de problème sélectionné avec les preuves de tri de cette compétence. Au minimum, incluez :

ID du pipeline et étendue de charge de travail
URL du job représentatif
premier extrait d'échec causale
jobs correspondants ou familles de modèles affectées
propriétaire probable ou sous-système quand connu
hypothèse au niveau du code quand applicable
pourquoi une PR n'a pas été créée encore

Respectez la structure obligatoire et les conseils de sécurité du template. Ne collez pas de tokens sensibles, d'identifiants privés ou d'autres secrets dans le corps du problème.

Préférez un problème par bucket, pas un problème par job.

Garde-fous des PR

Avant d'ouvrir une PR :

vérifiez qu'il n'y a pas de PR ouverte existante pour le même bucket ou signature d'échec
confirmez que le repo cible de PR correspond au propriétaire du bucket
assurez-vous que le correctif proposé est soutenu par les preuves des logs et du code
assurez-vous que la description de PR explique pourquoi un changement couvre tous les jobs du bucket

Pour les PRs TensorRT-LLM, suivez le workflow du repo :

utilisez le format de titre PR local : [JIRA/NVBUG/None][type] description
gardez la PR focalisée sur une préoccupation
validez seulement les tests ou commandes les plus petits pertinents

Garde-fous des Problèmes

Avant d'ouvrir un problème :

vérifiez qu'il n'y a pas de problème ou PR ouvert existant pour le même bucket ou signature d'échec
confirmez que le repo cible du problème est la meilleure maison disponible pour le bucket
assurez-vous que le problème explique pourquoi aucune PR n'a été créée
incluez assez de preuves qu'un autre ingénieur peut le reprendre sans refaire le tri initial
utilisez le fichier approprié de .github/ISSUE_TEMPLATE/, généralement 06-bug-report.yml pour les buckets d'échec de cette compétence

Template de Corps de PR

Utilisez cette structure :

## Résumé
- Corrige le bucket de cause racine : `<repo/component/failure-mode>`
- Résout les échecs du pipeline `<pipeline_id>`
- Un changement couvre `<N>` jobs correspondants parce que `<shared-cause>`

## Preuves
- Job représentatif : `<job_url>`
- Extrait de log représentatif : `<first causal failure>`
- Jobs correspondants : `<count>` dans `<models/workloads>`
- Règle de bucket : `<pourquoi ces échecs appartiennent ensemble>`

## Validation
- `<étape de test ou de vérification focalisée>`

## Non Inclus
- `<buckets infra uniquement ou à preuves mitigées ignorés>`

Phase 4 — Rapport Final

Imprimez un rapport final concis avec :

pipeline cible, pipeline terminal et étendue de charge de travail
tous les buckets avec statut tel que actionable ou issue-only
preuves représentatives pour chaque bucket actionnaire
PRs créées, problèmes créés ou pourquoi aucune PR n'a été créée pour un bucket issue-only
risques restants ou validation de suivi

Le rapport final doit également inclure une somme de contrôle de catégorisation :

total failed jobs = <N>
sum of bucket sizes = <N>

Si aucune PR ou problème n'a été créé, dites-le explicitement et expliquez si le bloqueur était :

vérifications de doublon pas encore effectuées
preuves trop faibles pour un propriétaire de code concret
aucun correctif unique cohérent
propriété externe ou infra

Respectez le format de sortie sélectionné par l'utilisateur :

chat : imprimez le rapport final directement dans le chat
md : écrivez également le rapport final dans un fichier Markdown
csv : écrivez également un CSV par défaut avec une ligne par job échoué, incluant au minimum ID du job, URL du job, charge de travail/modèle, première erreur causale, bucket, propriétaire probable et résultat

Anti-Patterns

Ne faites pas confiance à une catégorie héritée sans lire les logs.
Ne dépendez pas du code autodeploy-dashboard pour résoudre les pipelines ou classer les échecs.
Ne vous arrêtez pas au premier bridge échoué si les vrais échecs model-coverage sont plus profonds dans la chaîne de déclenchement aval.
Ne fusionnez pas les échecs juste parce qu'ils mentionnent le même modèle.
Ne créez pas une PR pour un bucket qui correspond à plusieurs correctifs sans rapport.
N'ouvrez pas de PRs pour les buckets infra uniquement.
Ne cachez pas l'incertitude ; si les preuves sont mitigées, divisez ou ignorez.

ad-pipeline-failure-pr