Résoudre les retours sur PR GitHub
Résumez les retours non résolus sur la PR, générez un patch et rédigez des réponses en une seule passe.
Aperçu
Les revues de PR avancent plus vite lorsque les retours restants sont clairs et actionnables. L'agent de résolution des retours sur PR GitHub récupère les commentaires non résolus d'une ou plusieurs pull requests, les regroupe en un ensemble de tâches ciblées et identifie ce qui bloque la fusion par opposition à ce qui est simplement souhaitable. Il utilise ensuite l'action Glean code writer pour générer un patch prêt à appliquer et rédige des réponses concises aux relecteurs, afin que les ingénieurs puissent boucler la boucle avec moins de changements de contexte.
Voyez-le en action
Fonctionnalités
- Agrège les commentaires de revue non résolus sur une ou plusieurs PR et les regroupe par fichier, type de sujet et gravité, afin d'éviter aux ingénieurs de suivre les fils un par un.
- Identifie quels éléments bloquent la fusion par opposition à ceux qui sont simplement souhaitables, et transforme chaque groupe en tâche concrète.
- Génère un patch ciblé, prêt à appliquer, qui traite les retours à forte confiance et relie les changements aux commentaires exacts qu'ils résolvent.
- Rédige des réponses concises et techniques, prêtes à être collées dans les fils de revue, et aide à faire avancer les échanges.
Exemple de résultat
Dépôt : <span class="text-color-green">internal-platform/api-gateway</span>
Pull request : #482 Ajouter la limitation de débit à l'API publique
Statut : Ouverte, 1 relecteur, 2 commentaires non résolus
Résumé
- Toutes les préoccupations de conception de haut niveau sont traitées
- Le travail restant est concentré sur la validation de la configuration
Points de revue en attente
- Validation et valeurs par défaut de la configuration (bloquant)
- <span class="text-color-green">config/rate_limiting.yaml:</span> Ajouter une validation garantissant que requests_per_minute est supérieur à zéro
- <span class="text-color-green">config/rate_limiting.yaml:</span> Fournir une valeur par défaut pour burst_size lorsqu'elle n'est pas spécifiée, le comportement actuel considérant l'absence comme zéro
Changements de code et correctifs proposés
1. Validation de la configuration
Fichier : <span class="text-color-green">config/rate_limiting.yaml</span> (logique de chargement dans <span class="text-color-green">config/loader.go</span>)
- Avant d'appliquer la configuration, ajouter une étape de validation :
<span class="text-color-green">if cfg.RequestsPerMinute <= 0 {</span>
<span class="text-color-green">return fmt.Errorf("rate limiting: requests_per_minute must be > 0, got %d", cfg.RequestsPerMinute)</span>
<span class="text-color-green">}</span>
<span class="text-color-green">if cfg.BurstSize == 0 {</span>
<span class="text-color-green">cfg.BurstSize = cfg.RequestsPerMinute</span>
<span class="text-color-green">}</span>
Cela résout les commentaires d'Alice sur les configurations invalides et les valeurs par défaut manquantes.
Brouillons de réponses aux relecteurs
Pour Alice :
J'ai ajouté une validation pour <span class="text-color-green">requests_per_minute > 0</span> et défini <span class="text-color-green">burst_size</span> par défaut à <span class="text-color-green">requests_per_minute</span> lorsqu'il n'est pas renseigné. Cela devrait empêcher les configurations invalides de démarrer avec succès et correspond au comportement que vous avez décrit.
Workflow de l’agent
Étape 1 : Identifier les PR cibles
L'utilisateur fournit une ou plusieurs URL de pull request GitHub pour exécuter l'agent. L'agent résout chaque lien en une PR et récupère les métadonnées clés comme le titre, l'auteur, les relecteurs, le statut et les issues liées.
Étape 2 : Récupérer les commentaires et fils ouverts
Pour chaque PR, l'agent récupère les commentaires inline, les fils de revue non résolus et les résumés de revue de premier niveau ou les demandes de changements. Les retours résolus ou remplacés sont filtrés afin que la sortie reste ciblée.
Étape 3 : Analyser et regrouper les retours
L'agent regroupe les commentaires restants par fichier, type de sujet et gravité. Les retours dupliqués ou étroitement liés sont fusionnés en un seul élément actionnable.
Étape 4 : Élaborer un plan de résolution
Chaque groupe de retours est traduit en une tâche concrète avec périmètre et fichiers pertinents identifiés. Les tâches sont ordonnées pour traiter d'abord les éléments bloquants pour la fusion.
Étape 5 : Générer les correctifs avec code writer
Pour les groupes à forte confiance, l'agent invoque l'action code writer avec les fichiers pertinents, le contexte du diff et les commentaires des relecteurs. Il produit des modifications ciblées destinées à résoudre les retours tout en respectant les modèles et le style existants du dépôt.
Étape 6 : Associer les changements aux fils de revue
L'agent relie chaque changement généré au fil de commentaire d'origine, afin qu'il soit clair quelle ligne de code et quel commit traitent quel retour.
Étape 7 : Rédiger les réponses aux relecteurs
Pour chaque fil en attente, l'agent rédige une réponse courte et technique qui confirme ce qui a changé et où, explique pourquoi une demande n'a pas été appliquée, ou pose une question de clarification lorsque les exigences ne sont pas claires.
Étape 8 : Produire le résumé final
L'agent génère un résumé au niveau de la PR couvrant le statut, le travail restant, les correctifs proposés, les tests et des réponses prêtes à coller pour GitHub, Slack ou un outil de suivi des tâches.
Work AI qui fonctionne.
