Passer au contenu principal
Venez à bout d’un backlog de PR qui s’accumule. Cette automatisation planifiée met en évidence les pull requests qui se sont enlisées — plus de commentaires, plus de commits, plus aucune activité — et agit en conséquence : un message amical à l’auteur, un rebase si la branche n’est plus à jour, ou une fermeture propre si la PR a été abandonnée depuis des semaines.

Utiliser ce modèle

Ouvrez Stale PR Cleanup dans Devin et créez l’automatisation avec la configuration par défaut. Vous pouvez la personnaliser avant de l’enregistrer.

​
Ce que fait cette automatisation

Les pull requests (PR) obsolètes freinent la vélocité de l’équipe. Les relecteurs les ignorent, les auteurs les oublient, et les conflits s’accumulent jusqu’à ce que la fusion devienne un mini-projet. Ce modèle s’exécute chaque semaine, repère les PR restées inactives au-delà d’un seuil que vous définissez, puis effectue des actions de nettoyage adaptées au contexte : relance, rebase ou fermeture.

​
Comment ça marche

Déclencheur : Événement de planification — recurring
  • Événement : schedule:recurring
    • Conditions :
      • rrule correspond à FREQ=WEEKLY;BYDAY=WE;BYHOUR=10;BYMINUTE=0
Ce que fait Devin : Lance une session avec tout le contexte de l’événement, exécute le prompt ci-dessous et, éventuellement, 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.

​
Configuration

  1. Ouvrez Automations → Templates dans Devin.
  2. Cliquez sur Stale PR Cleanup. La page de création s’ouvre avec ce modèle déjà prérempli.
  3. Connectez toutes les intégrations requises et installez les serveurs MCP si ce n’est pas déjà fait.
  4. Remplacez les valeurs d’exemple dans les conditions de déclenchement (par exemple, remplacez your-org/your-repo par votre vrai repo).
  5. Passez en revue le prompt et adaptez-le au langage, aux conventions et aux garde-fous de votre équipe.
  6. Cliquez sur Create automation.
La plupart des modèles d’automatisation incluent des limites suggérées d’ACU et d’invocation pour maîtriser les coûts au début du rollout. Laissez-les telles quelles jusqu’à ce que vous soyez sûr du comportement de l’automatisation, puis augmentez-les en fonction de votre charge de travail.

​
Quand utiliser ce modèle

  • Équipes d’ingénierie avec d’importants flux de contributions open source
  • Dépôts internes avec de longs backlogs de PR et d’importants goulets d’étranglement dans les revues
  • Maintenir les branches principales à l’abri des conflits de fusion causés par des branches oubliées
  • Réduire la charge cognitive des relecteurs qui parcourent la liste des PR

​
Idées de personnalisation

  • Ajustez le seuil d’inactivité (7 jours, 30 jours, 90 jours)
  • Limitez le périmètre à des repos ou des libellés spécifiques
  • Ajoutez un commentaire d’avertissement avec un délai de grâce avant toute action destructive
  • Intégrez Slack afin que les auteurs reçoivent un message privé, et pas seulement une notification GitHub

​
Voir aussi