Points clés à retenir
- Écrire du code n’est plus la partie lente. En 31 jours, notre repo principal a fusionné 473 demandes de fusion. 130 d’entre elles nécessitaient que quelqu’un revienne et fusionne main dans la branche, 239 commits de fusion au total, et 238 d’entre eux ont été faits par une personne.
- Les demandes de fusion qui en avaient besoin ont pris une médiane de 44 heures de l’ouverture à la fusion. Celles qui n’en avaient pas besoin ont pris 2 heures. Des 60 demandes de fusion restées ouvertes plus longtemps que trois jours, 51 ont nécessité au moins une fusion de main.
- babysit-pr divise le travail à un label :
LGTM, « looks good to me », que l’auteur ajoute quand le travail est terminé. Avant cela, une compétence garde l’agent sur la demande de fusion jusqu’à ce que CI soit vert et que chaque bot de révision ait répondu. Après cela, un flux de travail GitHub Actions garde la demande de fusion fusionnable jusqu’à ce qu’une personne la fusionne, et ajouteRTM, « ready to merge », une fois que quelqu’un d’autre que l’auteur approuve. - Le flux de travail ne fusionne jamais, ne ferme jamais, et ne change jamais une ligne que l’auteur a écrite. Un conflit qu’il ne peut pas résoudre autour du code de l’auteur revient à l’auteur comme
REWORK. - La compétence est publique, sous licence MIT : babysit-pr-skill sur GitHub , avec le script de surveillance et la conception du flux de travail. Le flux de travail lui-même est toujours en mode de simulation sèche sur notre repo, et j’explique ci-dessous pourquoi.
Pourquoi les demandes de fusion terminées deviennent-elles obsolètes ?
Écrire le code a cessé d’être la partie lente. Avec le modèle architecte et les agents faisant la plupart de la saisie, notre repo prend environ 13 commits par jour dans main. C’est bon pour l’expédition et mauvais pour chaque demande de fusion ouverte, car chacun de ces commits peut mettre une demande de fusion en conflit ou rendre son CI rouge.
J’ai récupéré les 31 derniers jours de demandes de fusion fusionnées pour voir où le temps s’est écoulé.
Le 44 contre 2 est une corrélation, pas une cause. Une demande de fusion qui reste ouverte plus longtemps donne à main plus de temps pour se déplacer sous elle, donc elle est plus susceptible de nécessiter une fusion. Mais les fusions elles-mêmes sont du vrai travail que quelqu’un a fait 239 fois en un mois. Cinq personnes en ont fait 238 à la main. Une demande de fusion a nécessité huit fusions de main sur les sept jours où elle était ouverte.
L’approbation elle-même a été rapide. Une fois qu’une demande de fusion a obtenu sa première approbation, le temps médian pour fusionner était zéro heure. L’attente s’est produite avant cela : l’auteur a terminé, puis la demande de fusion a attendu qu’un rédacteur la voie, et pendant qu’elle attendait, main s’est déplacé. Nous avons commencé à étiqueter les demandes de fusion terminées LGTM le 20 octobre. Les 20 qui ont fusionné depuis ont attendu une médiane de 38 heures entre LGTM et fusion, et un sur quatre a attendu plus de 78 heures.
C’est l’écart pour lequel ceci est destiné. Personne n’est négligent ici. L’auteur pense que c’est terminé, le rédacteur ne l’a pas encore ouvert, et la branche pourrit entre les deux.
Prêt à développer votre entreprise?
Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.
Pourquoi ne pas fermer les demandes de fusion obsolètes avec actions/stale ?
La réponse habituelle aux demandes de fusion obsolètes est actions/stale : une action GitHub qui ajoute un label stale aux problèmes et demandes de fusion après un nombre défini de jours d’inactivité, et les ferme automatiquement quelques jours plus tard à moins que quelqu’un ne commente ou ne pousse.
Cela correspond à une demande de fusion sur laquelle personne ne travaille. Elle ne fait rien pour celle que nous avions. Les nôtres étaient du travail terminé qui est devenu obsolète pendant qu’elles attendaient un rédacteur, parce que main s’est déplacé sous elles. Les fermer jette le travail, et un label stale dit à l’auteur ce qu’il sait déjà. Ce dont la demande de fusion a besoin, c’est que quelqu’un fusionne main dedans, réexécute le travail CI rouge et le garde vert jusqu’à ce qu’une personne l’approuve. Donc au lieu de fermer les demandes de fusion obsolètes, nous les gardons fusionnables.
Comment babysit-pr garde les demandes de fusion fusionnables
La division suit qui attend. Avant LGTM l’auteur est toujours sur la demande de fusion, généralement une session d’agent, et la compétence garde cette session à faire du travail utile au lieu de déclarer la victoire quand le code se compile. Après LGTM l’auteur s’est éloigné, donc le travail va à quelque chose qui n’a pas besoin d’eux : un flux de travail qui s’exécute que quelqu’un regarde ou non.
LGTM signifie « looks good to me ». Sur la plupart des équipes, un rédacteur le dit à propos du code de quelqu’un d’autre. Ici l’auteur l’ajoute sur sa propre demande de fusion comme un label qui signifie « je suis terminé, il ne me reste rien à faire ». C’est la parole d’une personne : l’agent ne l’ajoute que quand il lui a été dit de remettre la demande de fusion. Ce label est l’opt-in pour tout ce qui suit, et c’est la chose qui rend un développeur à l’aise de laisser un bot faire un push sur sa branche.
Rejoignez notre newsletter
Recevez gratuitement les derniers conseils, tendances et offres.
Avant LGTM : une compétence Claude Code porte la demande de fusion à prêt
La compétence a commencé comme la compétence babysit-pr dans le tstack
de Theo Browne. J’ai gardé son observateur et ses règles principales et j’ai changé où il s’arrête.
Un observateur par demande de fusion
pr-wait interroge une demande de fusion et imprime une ligne par événement réel : une vérification a échoué, toutes les vérifications ont été terminées, quelqu’un a commenté ou révisé, main s’est déplacé sous les fichiers que cette demande de fusion touche, la branche a pris du retard ou est entrée en conflit, la demande de fusion a fusionné. Dans Claude Code, elle s’exécute sous l’outil Monitor, donc chaque ligne réveille l’agent une fois. Un événement qui n’a besoin d’aucune action termine le tour sans message. « Toujours en attente » n’est pas une nouvelle, et un agent qui le dit cinquante fois remplit son propre contexte de rien.
Triez le travail CI rouge avant de toucher le code
Il y a quatre types de rouge, et un seul est une correction de code :
- La demande de fusion l’a cassé. Corrigez-la avec le plus petit changement.
- Le runner a buggé. Réexécutez les travaux défaillants une fois. Un deuxième échec sur la même head n’est pas un bug.
- Main est rouge. Ne corrigez pas main sur la branche de fonctionnalité de quelqu’un. Rapportez-le et attendez.
- Une vérification de processus est rouge, par exemple la demande de fusion ne lie pas un problème approuvé. C’est une étape pour une personne.
Les agents livrés à eux-mêmes traitent les quatre comme le premier, et la demande de fusion grandit d’une contournement pour un test qui est cassé sur main.
Prouvez une conclusion de révision avant de la corriger
Une conclusion de révision que l’agent accepte obtient d’abord un test échouant, puis la correction. Une conclusion qu’il rejette obtient une raison écrite. C’est la même règle que notre compétence de révision prouvée, et c’est ce qui arrête les bots de révision de diriger une demande de fusion par volume.
Gardez la demande de fusion à la taille de son objectif
Les boucles de révision font grandir une demande de fusion une correction pas chère à la fois : une protection pour un cas limite que personne ne touche, un test pour un comportement qui n’a pas changé, une réduction de compatibilité. La compétence corrige les vrais bugs dans le cas prévu et décline le reste par écrit. Les valables deviennent des problèmes.
Prêt est une liste de contrôle
Chaque travail CI de gating vert sur la head actuelle, chaque bot de révision terminé sur cette head, rien n’attend une personne, pas de fil non résolu, pas de conflit. Quand cela tient, l’agent le rapporte et arrête de surveiller.
Après LGTM : un flux de travail GitHub Actions résout les conflits de fusion
Le flux de travail a deux travaux.
La porte décide ce dont chaque demande de fusion a besoin
La porte est bon marché : pas d’agent, pas de vérification du code de demande de fusion. Elle s’exécute à chaque push vers main, chaque achèvement de CI, chaque label et révision, et toutes les 30 minutes, et une requête GraphQL lui donne chaque demande de fusion LGTM ouverte. Pour chacune, une fonction pure décide quoi faire. Ajoutez RTM si elle est approuvée par quelqu’un d’autre que l’auteur, verte, et sans conflit. Laissez-la tranquille si une révision s’exécute. Réexécutez CI rouge une fois. Envoyez un conflit, ou CI qui est toujours rouge après sa réexécution, au correcteur.
L’agent correcteur fusionne main dedans
Le correcteur est un travail d’agent pour une demande de fusion sur une head. Il fusionne main dans la branche sans commiter, donne à l’agent les fichiers en conflit et les journaux défaillants, et laisse celui-ci éditer uniquement les fichiers en conflit et les fichiers que la demande de fusion change déjà. Ensuite, il pose une question.
Cette demande de fusion peut-elle atterrir sans changer une ligne que son auteur a écrite ?
Si oui, le verdict est MODERNIZE. L’agent résout le conflit autour des lignes de l’auteur, un validateur vérifie le résultat, et le flux de travail pousse un commit de fusion normal. Si non, parce que main a supprimé la fonction que la demande de fusion édite ou que le code de la demande de fusion échoue CI, le verdict est REWORK. Rien n’est poussé, LGTM est supprimé, et l’auteur reçoit un commentaire avec la plus petite réécriture. Si main fait déjà ce que la demande de fusion fait, le verdict est CLOSE, et une personne la ferme.
Le validateur garde chaque ligne que l’auteur a écrite
Le validateur est ce qui maintient la règle. Il rejette toute fusion qui supprime une ligne que la demande de fusion a ajoutée, ou une ligne que main a ajoutée à un fichier en conflit. Il rejette les éditions en dehors des fichiers autorisés, les marqueurs de conflit restants, et les changements aux fichiers CI ou de sécurité. Un agent qui essaie de « corriger » le code de l’auteur se termine avec un label demandant un humain, jamais avec un push. Le flux de travail pousse sans force, et uniquement si la branche n’a pas bougé depuis que la tentative a commencé. Une tentative par head et base, deux par head, trois commentaires par demande de fusion par jour.
Il ne fusionne jamais
RTM, « ready to merge », est la déclaration de la porte qu’une demande de fusion a tout ce dont elle a besoin : le LGTM de l’auteur, une approbation de quelqu’un d’autre, CI vert et pas de conflit. Une personne fait la fusion. Cela a gardé la conception petite, et cela a gardé l’argument quant à si un bot devrait fusionner hors de la révision.
Qu’est-ce qui change pour l’auteur, le rédacteur et quiconque fusionne
L’auteur dit terminé une fois. Il ne revient pas trois jours plus tard pour fusionner main et attendre CI à nouveau, et une demande de fusion d’agent ne pourrit pas parce que la session qui l’a ouverte s’est terminée.
Le rédacteur ouvre une demande de fusion qui est verte et fusionnable sur aujourd’hui’s main, donc son approbation est la dernière étape et non le début d’une autre ronde.
Quiconque fusionne travaille à partir d’une liste. RTM reste une fois que la porte l’ajoute, et si main casse la demande de fusion après cela, le flux de travail la corrige et le label reste.
Et l’auteur garde le contrôle de son code. Le pire que le bot peut faire à une branche est ajouter un commit de fusion qu’un validateur a vérifié ligne par ligne.
Pourquoi notre ancien réglementeur de conflit de fusion n’a jamais fonctionné
Nous avions un réglementeur de conflit avant celui-ci. Un détecteur a trouvé les demandes de fusion en conflit et a commenté sur elles, et le réglementeur s’est exécuté quand quelqu’un a ajouté un label le demandant. Dans la même période, le détecteur s’est exécuté environ 2 500 fois. Le réglementeur s’est exécuté zéro fois.
Je ne pense pas que quelqu’un était paresseux. Un développeur qui considère une demande de fusion comme terminée ne revient pas la presser. L’automatisation qui attend d’être demandée ne sera pas demandée. C’est pourquoi celui-ci commence par LGTM, le moment où l’auteur dit qu’il a terminé, et fait le reste sans eux.
Qu’est-ce qui ne fonctionne pas encore ?
Deux choses, et je préfère les dire ici plutôt que de vous les faire découvrir.
Le flux de travail est en mode de simulation sèche
Sa porte ne journalise que ce qu’elle ferait jusqu’à ce qu’une variable de référentiel dise le contraire. Avant d’aller aussi loin, une révision qui ne garde que les conclusions qu’elle peut prouver avec un test défaillant a trouvé onze bugs dedans. Quelques-uns valent la peine de savoir si vous en construisez un. La recherche de label de GitHub prend du retard, donc une demande de fusion qu’elle retourne peut avoir perdu le label il y a quelques secondes, et la décision doit vérifier les labels en direct. Un marqueur « this head already had its re-run » écrit avant que l’appel de réexécution réussisse laisse un appel API défaillant utiliser la seule nouvelle tentative de la head. Et une vérification « lose no line » qui ne suit pas les renommages voit chaque ligne d’un fichier renommé comme perdue.
Les runners d’agents sont tombés en panne
Depuis le 19 octobre, chaque travail destiné à nos runners d’agents a échoué à obtenir une machine : 406 annulés, 24 toujours en file d’attente quand j’ai vérifié. La porte s’exécute ailleurs et va bien, mais le correcteur a besoin d’un runner d’agent, et un mort ressemble exactement à un jour calme. Rien n’a échoué bruyamment. Les travaux ont été mis en file d’attente puis annulés. Si vous construisez ceci, alertez sur les exécutions du correcteur qui s’assoient en file d’attente.
Les nombres ci-dessus sont donc la photo avant. En ce moment nous avons 27 demandes de fusion LGTM ouvertes, 7 d’entre elles avec CI rouge et aucune avec RTM. Ce sont les nombres que ceci devrait changer, et je rapporterai ce qu’il a fait.
Comment installer la compétence babysit-pr
github.com/LivinTribunal/babysit-pr-skill a :
SKILL.md, la compétence, avec une courte section « configure once » pour vos flux de travail CI, bots de révision et vérifications de processus.scripts/pr-wait, l’observateur. Il a besoin de Python et d’unghauthentifié.docs/after-lgtm.md, la conception du flux de travail après-LGTM: les labels, la porte, le correcteur, la règle qu’il ne change jamais les lignes de l’auteur, et les onze bugs.
Le flux de travail est une conception plutôt qu’un fichier à copier, parce que le nôtre s’exécute contre les labels, runners et CI d’une seule entreprise. Construisez le vôtre à partir du doc, expédiez-le en mode log-only, lisez un jour de ses décisions, puis allumez-le.
Il s’apparie avec le modèle architecte , qui décide qui écrit le code, et grain , qui décide à quoi ressemble le code. babysit-pr est ce qui se passe après que l’un ou l’autre ouvre la demande de fusion. Si vous réglez l’agent lui-même, le test A/B CLAUDE.md et la limite de contexte qui a réduit l’utilisation des tokens de 17 % couvrent les instructions et le coût.
