Centre d'aide · Résoudre

Que faire quand un run se termine en échec ?

Lire la catégorie d'erreur, comprendre ce qu'elle veut dire, et savoir s'il faut relancer.

Ouvrez le run dans Runs : la catégorie d'erreur est affichée en haut, et c'est elle qui dit quoi faire. Un échec n'est pas forcément une panne — le plus souvent, le pipeline a refusé de livrer un travail qu'il jugeait insuffisant.

Que veulent dire les catégories d'erreur ?

Vérification insuffisante — le code produit n'a pas atteint le score minimal, même après les tentatives de correction. La merge request existe, en brouillon, avec les reproches en commentaire. Lisez-les : souvent l'issue était ambiguë, parfois une convention interne manque à vos contextes.

Question sans réponse — l'agent lecteur avait besoin d'une précision et personne n'a répondu. Voir Diavi me pose une question.

Intervention humaine nécessaire — le pipeline a rencontré quelque chose qu'il ne sait pas trancher seul. La merge request contient ce qui a pu être fait, et le commentaire dit où ça bloque.

Réponse trop longue — le modèle a atteint son plafond de sortie en plein travail. Cela arrive sur les issues qui touchent beaucoup de fichiers d'un coup. Découpez l'issue en deux et relancez.

Infrastructure — un incident de notre côté. Ce run n'est pas décompté de votre quota. Relancez ; si ça se reproduit, écrivez-nous.

Faut-il relancer ?

Relancer à l'identique ne sert que si l'échec était une erreur d'infrastructure. Dans tous les autres cas, changez quelque chose d'abord : préciser l'issue, la découper, ou ajouter la convention manquante à vos contextes. Sans changement, le second run rencontrera le même mur que le premier — et comptera dans votre quota.

Où voir le détail ?

L'onglet Logs montre le déroulé complet, étape par étape. Un glossaire y explique les termes qui reviennent.