Erkennen

Pull-Request-Reviews

Jeder Pull Request in einem verbundenen Repository wird gegen die Produktion geprüft, auf die er deployt, und du erfährst davon, bevor du mergst.

Die meisten Incidents beginnen mit einer Änderung. Polylane prüft jeden Pull Request in einem verbundenen Repository gegen die Produktionsressourcen, auf die er deployt, und postet einen Kommentar, der bestanden oder nicht bestanden sagt.

Was es leistet

Ein Agent liest den Diff und die Live-Metriken, Logs und offenen Issues der Ressourcen, auf die das Repository deployt, und entscheidet dann, ob die Änderung der Produktion schaden kann. Du bekommst einen Kommentar am Pull Request, optional einen Check Polylane production impact und einen Thread in der Konsole mit der vollständigen Analyse.

So funktioniert es

  1. Einen Pull Request gegen den Default-Branch zu öffnen, darauf zu pushen oder ihn als bereit für Review zu markieren, startet ein Review seines Head-Commits. Entwürfe werden nicht geprüft.
  2. Ein späterer Push ersetzt das laufende Review, sodass nur der jüngste Commit beurteilt wird.
  3. Änderungen, die nur Dokumentation, Tests oder CI-Dateien berühren, bestehen ohne Untersuchung.
  4. Polylane folgt den Deploy-Kanten des Repositories zu seinen Produktionsressourcen oder prüft gegen die Cloud-Konten des Workspace als Ganzes, wenn es keine hat.
  5. Der Agent untersucht in einem Thread und hält ein Urteil pass oder fail fest.
  6. Ein Kommentar pro Pull Request wird bei jedem Review bearbeitet. Ein Fail lautet Hold this merge mit der Auswirkungsstufe und dem Befund; ein Pass lautet Production impact unlikely oder sagt, ob ein Fix für ein erkanntes Issue es voraussichtlich löst. Wenn ein späterer Push ein Bedenken ausräumt, springt der Kommentar zurück auf Pass und sagt das auch.

Der Agent kann außerdem Observability-Verbesserungen vorschlagen, als ein gebündeltes Review mit Vorschlagskommentaren oder als gestapelten Pull Request. Sie beeinflussen das Urteil nie.

Auf ein Review reagieren

Erwähne @polylane in einem Kommentar am Pull Request, und Polylane antwortet in derselben Konversation; Nicht-Mitglieder erhalten stattdessen einen Hinweis zum Zugriff.

Du bittest umWas passiert
Eine FrageDer Agent antwortet aus dem Review-Thread, mit den Belegen vor Augen.
Einen zweiten BlickDer Agent prüft den jüngsten Push erneut und überdenkt das Urteil.
Einen FixPolylane startet einen Fix-Run und öffnet einen gestapelten Pull Request gegen den Branch des Pull Requests, verlinkt aus dem Kommentar.

Der Tab Changes des Repositories in der Konsole listet jedes Review auf. Ein Fail bietet Fix with Polylane, das denselben Fix-Run startet, und Dismiss, wenn das Bedenken nicht zutrifft: Der Pull Request wird weiter geprüft, bekommt aber keine Kommentare mehr, bis du ihn mit Restore zurückholst.

StatusBeschreibung
In reviewPolylane prüft den jüngsten Push.
FlaggedDas Review hat ein Produktionsbedenken gefunden.
PassedKeine Produktionsbedenken gefunden.
ResolvedEin späterer Push hat die Bedenken ausgeräumt.
DismissedEin Mitglied hat das Review verworfen; der Pull Request bekommt keine Kommentare mehr.

Konfigurieren

Reviews sind für jedes verbundene Repository an. Settings > Pull request reviews schaltet sie workspaceweit aus und legt fest, ob Review-Threads mit Betrachtern des Pull Requests geteilt werden. Unter Settings > Repositories ergänzt der Tab Settings eines Repositories drei Felder.

FeldBeschreibung
Review pull requests for production impactSchaltet Reviews nur für dieses Repository aus.
Pull request review instructionsFreitext, den der Agent bei jedem Review liest: deploy-kritische Pfade oder Bedenken, die andere Prüfstellen bereits abdecken.
Block merging on production concernsPostet den Check Polylane production impact an jedem geprüften Pull Request; er schlägt bei einem Bedenken fehl. Standardmäßig an. Verlange ihn in der Branch Protection, um Merges zu blockieren.

Der Check wird auch an Merge-Queue-Commits abgeschlossen, da der Pull Request geprüft wurde, bevor er in die Warteschlange kam. Ein Fail-Urteil kann die E-Mail Production Concern Found senden, standardmäßig aus unter Benachrichtigungen.

Hinweise zu Plänen

Jeder Plan enthält eine monatliche Zahl von Pull-Request-Reviews; das Kontingent des Free-Plans steht unter Abrechnung und Nutzung, und Mitglieder werden per E-Mail informiert, wenn es knapp wird. Über dem Kontingent hält die Konsole den Pull Request als Production impact not verified fest, und nichts wird auf GitHub gepostet.

Verwandt

  • Repositories, um ein Repository zu verbinden und seine Ressourcen zu verknüpfen.
  • Fix-Runs dafür, wie ein Review-Thread zu seinem Urteil kommt.
  • Autofix für die Pull Requests, die ein Fix-Run öffnet.
  • Benachrichtigungen für die E-Mail, die ein nicht bestandenes Review senden kann.