Les tâches échouent. La plupart des échecs proviennent de problèmes de configuration ou de spécifications, et non de causes mystérieuses ; ils se classent en quelques catégories bien précises.
Tout d’abord, lisez où l’exécution s’est arrêtée.
Le journal d’exécution indique à quel stade l’échec s’est produit. Ce simple fait permet de cerner la cause plus efficacement que tout autre élément :
| Échec au niveau de | Signifie presque toujours |
|---|---|
| Avant même que du code ne soit écrit | La commande de build ou d’installation est incorrecte pour un espace de travail propre. |
| Pendant la modification | Un travail particulièrement ardu ou une dépendance manquante. |
| Exécution des tests | La commande de test est incorrecte, ou le jeu de tests nécessite un service associé. |
| Vérification | Une étape bloquante ; consultez les constatations. |
| Révision | Des constatations qui n’ont pas pu être corrigées automatiquement. |
Les échecs avant la rédaction de la modification relèvent de la configuration. Consultez La configuration du build et des tests..
Ce n’est pas bloqué, c’est simplement mis en file d’attente.
Une tâche dans PENDING n’est pas bloquée. Elle attend une place disponible pour un agent. Vérifiez
la capacité avant toute autre chose — c’est l’alerte fausse la plus courante.
Cela vous demande quelque chose.
NEEDS_HUMAN_REVIEW signifie que la tâche a rencontré une décision que seul vous pouvez prendre. Ce n’est pas une
erreur. Répondez à la question et elle reprendra là où elle s’était arrêtée.
Répondez avec précision. Une réponse vague entraînera une nouvelle tentative et un nouveau retard.
Exécution beaucoup plus longue que prévu
Deux causes fréquentes :
Un jeu de tests lent ou bloqué. Coroid exécute votre jeu de tests ; s’il se bloque dans un espace de travail propre, la tâche reste en attente. Pour reproduire le problème, lancez le jeu de tests sur un clone frais.
Une spécification trop large, au point que l’agent continue de trouver davantage de travail à faire. Le signe distinctif est une liste de fichiers qui s’allonge. Annulez, resserrez le périmètre avec une ligne explicite indiquant ce qui est hors périmètre, puis relancez l’exécution. Consultez Spécifications.
Choisir l’action à entreprendre
Par ordre croissant de coût :
- Répondre — pour
NEEDS_HUMAN_REVIEW. Solution la moins coûteuse, qui conserve tout le contexte. - Retravailler — le travail est correct mais incomplet. La tâche revient vers l’agent développeur avec vos constatations et son contexte intact.
- Mettre en pause — vous devez d’abord vérifier quelque chose. Cela libère la place occupée ; l’exécution peut être reprise.
- Réessayer — uniquement pour les échecs véritablement transitoires. Réessayer pour un problème de configuration ne ferait que le reproduire.
- Annuler et respécifier — l’approche ou le périmètre était incorrect. Solution la plus coûteuse, et souvent la meilleure option.
Échecs récurrents sur plusieurs tâches
Le même échec au même stade sur des tâches sans lien entre elles indique un problème de configuration du projet, et non un problème lié à la tâche. Arrêtez de relancer les tâches et corrigez la configuration.