Revues de pull requests
La plupart des incidents commencent par un changement. Polylane relit chaque pull request d'un dépôt connecté au regard des ressources de production sur lesquelles elle se déploie, et publie un commentaire qui dit réussite ou échec.
Ce que ça fait
Un agent lit le diff et les métriques, logs et issues ouvertes en direct des ressources sur lesquelles le dépôt se déploie, puis décide si le changement peut nuire à la production. Tu obtiens un commentaire sur la pull request, un check Polylane production impact facultatif et un thread dans la console avec l'analyse complète.
Comment ça marche
- Ouvrir une pull request vers la branche par défaut, y pousser, ou la marquer prête pour revue démarre une revue de son commit de tête. Les brouillons ne sont pas relus.
- Un push ultérieur remplace la revue en cours, donc seul le dernier commit est jugé.
- Les changements qui ne touchent que la documentation, les tests ou les fichiers de CI passent sans investigation.
- Polylane suit les arêtes de déploiement du dépôt jusqu'à ses ressources de production, ou relit au regard de l'ensemble des comptes cloud de l'espace de travail quand il n'en a aucune.
- L'agent investigue dans un thread et enregistre un verdict
passoufail. - Un commentaire par pull request est modifié à chaque revue. Un échec se lit Hold this merge avec le niveau d'impact et le constat ; une réussite se lit Production impact unlikely, ou dit si un correctif pour une issue détectée devrait la résoudre. Quand un push ultérieur répond à une préoccupation, le commentaire repasse en réussite et le dit.
L'agent peut aussi suggérer des améliorations d'observabilité, sous forme d'une revue groupée de commentaires de suggestion ou d'une pull request empilée. Elles n'affectent jamais le verdict.
Agir sur une revue
Mentionne @polylane dans un commentaire de la pull request et Polylane répond dans la même conversation ; les non-membres reçoivent plutôt une note sur l'accès.
| Tu demandes | Ce qui se passe |
|---|---|
| Une question | L'agent répond depuis le thread de revue, avec les preuves sous les yeux. |
| Un second regard | L'agent relit le dernier push et reconsidère le verdict. |
| Un correctif | Polylane démarre un fix run et ouvre une pull request empilée sur la branche de la pull request, liée depuis le commentaire. |
L'onglet Changes du dépôt dans la console liste chaque revue. Un échec propose Fix with Polylane, qui démarre le même fix run, et Dismiss quand la préoccupation ne s'applique pas : la pull request continue d'être relue mais ne reçoit plus de commentaires jusqu'à ce que tu la Restore.
| État | Description |
|---|---|
| In review | Polylane relit le dernier push. |
| Flagged | La revue a trouvé une préoccupation pour la production. |
| Passed | Aucune préoccupation pour la production trouvée. |
| Resolved | Un push ultérieur a répondu aux préoccupations. |
| Dismissed | Un membre a rejeté la revue ; la pull request ne reçoit plus de commentaires. |
Configurer
Les revues sont activées pour chaque dépôt connecté. Settings > Pull request reviews les désactive pour tout l'espace de travail et détermine si les threads de revue sont partagés avec les personnes qui voient la pull request. Sous Settings > Repositories, l'onglet Settings d'un dépôt ajoute trois champs.
| Champ | Description |
|---|---|
| Review pull requests for production impact | Désactive les revues pour ce dépôt seulement. |
| Pull request review instructions | Du texte libre que l'agent lit à chaque revue : chemins critiques pour le déploiement, ou préoccupations que d'autres garde-fous traitent déjà. |
| Block merging on production concerns | Publie le check Polylane production impact sur chaque pull request relue ; il échoue en cas de préoccupation. Activé par défaut. Exige-le dans la protection de branche pour bloquer la fusion. |
Le check se termine aussi sur les commits de la file de fusion, puisque la pull request a été relue avant d'entrer dans la file. Un verdict d'échec peut envoyer l'e-mail Production Concern Found, désactivé par défaut sous Notifications.
Notes sur les forfaits
Chaque forfait inclut un nombre mensuel de revues de pull requests ; l'allocation du forfait Free est indiquée sur Facturation et consommation, et les membres reçoivent un e-mail quand elle s'épuise. Au-delà de l'allocation, la console enregistre la pull request comme Production impact not verified et rien n'est publié sur GitHub.
Voir aussi
- Dépôts pour connecter un dépôt et relier ses ressources.
- Fix runs pour la façon dont un thread de revue atteint son verdict.
- Autofix pour les pull requests qu'un fix run ouvre.
- Notifications pour l'e-mail qu'une revue en échec peut envoyer.
Issues
Chaque problème que Polylane détecte ou reçoit de ton alerting devient une issue, traitée par un fix run dont le thread raconte toute l'histoire.
Advisories
Des recommandations par ressource pour les mauvaises configurations, les risques de résilience et les manques d'observabilité, chacune avec un correctif que tu peux confier à un agent.