Passer au contenu principal
L’automatisation CI Failure Fixer permet à vos pull requests de rester au vert sans intervention humaine. Chaque fois qu’une vérification CI échoue sur une PR non créée par Devin, Devin ouvre le job en échec, lit les logs de build et de test, identifie la cause racine, puis applique un correctif sur la même branche — avant de relancer la suite pour vérifier que la vérification est bien validée.

Utilisez ce modèle

Ouvrez CI Failure Fixer dans Devin et créez l’automatisation avec la configuration par défaut. Vous pouvez la personnaliser avant de l’enregistrer.
Besoin d’un guide pas à pas ? Consultez le tutoriel pas à pas pour CI Failure Fixer.

​
Ce que fait cette automatisation

Ce modèle relie le webhook check_run de GitHub à une session Devin. Devin dispose de tout le contexte de la demande de fusion (PR) et de l’URL du job en échec, ce qui lui permet de récupérer la branche, de reproduire l’échec en local et de mettre au point un correctif de façon itérative, sans même avoir à ouvrir votre ordinateur portable. L’automatisation inclut un garde-fou intégré qui ignore tout commit créé par devin-ai-integration[bot], afin que vous ne vous retrouviez jamais dans une boucle où Devin corrige son propre travail.

​
Comment cela fonctionne

Déclencheur : événement GitHub — check.run
  • Événement : github:check_run
    • Conditions :
      • action eq completed
      • check_run.conclusion eq failure
      • repository.full_name eq your-org/your-repo
Ce que fait Devin : démarre une session avec l’intégralité du contexte de l’événement, exécute le prompt ci-dessous et, si vous le souhaitez, vous avertit en cas d’échec.

​
Prérequis

​
Exemple de prompt

Le modèle inclut ce prompt. Vous pouvez le modifier après avoir cliqué sur Utiliser le modèle ou le laisser tel quel.

​
Mise en place

  1. Ouvrez Automations → Templates dans Devin.
  2. Cliquez sur CI Failure Fixer. La page de création s’ouvre avec ce modèle prérempli.
  3. Connectez les intégrations requises et installez les serveurs MCP si ce n’est pas déjà fait.
  4. Remplacez les valeurs d’espace réservé dans les conditions de déclenchement (par exemple, remplacez your-org/your-repo par votre repo).
  5. Passez en revue le prompt et adaptez-le à la langue, aux conventions et aux garde-fous de votre équipe.
  6. Cliquez sur Créer l’automatisation.
La plupart des modèles d’automatisation incluent des limites suggérées d’ACU et d’invocation pour maîtriser les coûts pendant la phase initiale du déploiement progressif. Conservez-les telles quelles jusqu’à ce que vous soyez sûr du comportement de l’automatisation, puis augmentez-les selon votre charge de travail.

​
Quand utiliser ce modèle

  • Des tests instables qui bloquent les fusions pendant la nuit ou en dehors des heures ouvrées
  • Des erreurs de lint, de typage et de formatage que vous préférez ne pas corriger à la main
  • Des imports manquants, des snapshots obsolètes et de petits échecs de test sur les PR de la communauté
  • Débloquer les développeurs sans détourner un autre ingénieur de son travail de fond

​
Idées de personnalisation

  • Limitez le périmètre du déclencheur à un seul repo ou étendez-le à tous les repos d’un org
  • Ajoutez une condition qui ne se déclenche que pour des noms de vérification spécifiques (par ex. uniquement lint, et non la matrice complète)
  • Augmentez le plafond d’ACU si votre suite de tests est longue à exécuter, ou baissez-le pour limiter les coûts
  • Enchaînez avec une notification Slack en cas d’échec afin qu’un relecteur humain puisse prendre le relais lorsque Devin abandonne

​
Voir aussi