Code-Review | kanman Dokumentation

kanman beteiligt sich am Code-Review wie ein guter Kollege. Sein unabhängiger Reviewer liest die Pull- und Merge-Requests Ihres Teams und hinterlässt klare, konkrete Kommentare. Wenn Menschen kanmans eigene Arbeit prüfen, liest es ihre Kommentare und handelt danach. Beides funktioniert mit GitHub und GitLab.

Merge-Requests von Menschen prüfen

Öffnen Sie Team > Code-Review (/<workspace>/teams/<team>/team/review). Wählen Sie unter Merge-Requests von Menschen prüfen, wann kanman prüft:

Auswahl	Was passiert
Aus	kanman prüft die Merge-Requests Ihres Teams nicht.
Auf Anfrage (Standard)	Schreiben Sie `@kanman review` in einen Merge-Request, fordern Sie kanman als Reviewer an oder weisen Sie ihm den Merge-Request zu. Nur Personen mit Schreibrechten im Repository können anfragen.
Jeder MR	kanman prüft jeden Merge-Request, den eine Person in den Repositories des Teams öffnet oder um Commits ergänzt. Entwürfe bleiben außen vor, bis sie bereit sind. Wählen Sie Repositories, um es auf diese zu beschränken; ohne Auswahl zählen alle Repositories des Teams. `@kanman review` funktioniert auch.

Die Seite zeigt außerdem kanmans eigene GitHub- und GitLab-Konten, wie sie unter Chat und Erwähnungen eingestellt sind, mit einem Link dorthin. Unter Weitere Namen, die als kanman gelten können Sie andere Namen ergänzen, zum Beispiel ein GitHub-Team namens kanman. Tippen Sie einen Namen ein und drücken Sie Enter.

Team-Tab, Code-Review: Merge-Requests von Menschen prüfen steht auf Jeder MR, die Repositories des Teams als Chips und der Hinweis, dass kanman nur kommentiert

kanman prüft jeden neuen Commit einmal. Wenn die Autorin erneut pusht, prüft kanman den neuen Stand und wiederholt sich nicht.

Was ein Review enthält

kanmans Reviewer checkt die Änderung aus, liest den Diff, führt die passenden Tests aus und berücksichtigt, was Ihre CI und Ihre Scanner bereits gemeldet haben (Linter, Security-Scanner, SonarQube). Dann ordnet er seine Befunde ein:

Blockierend: etwas, das sich vor dem Merge ändern muss, zum Beispiel falsches Verhalten, ein entfernter oder abgeschwächter Test oder ein Sicherheitsbefund, den die Änderung verursacht. Alle blockierenden Befunde stehen zusammen in einem Review-Kommentar: „Changes requested: 2 blocking findings“, jeweils mit Fundstelle, Begründung und Vorschlag zur Behebung.
Should und Nit: kleinere Punkte, jeweils als Kommentar an der Zeile.

Wenn nichts blockiert, sagt der Review-Kommentar das. Jeder Kommentar ist als von kanman, einem KI-Agenten, geschrieben gekennzeichnet.

Was kanman an Ihren Merge-Requests nie tut

kanman kommentiert nur. Es genehmigt, pusht oder mergt nie den Merge-Request einer Person: Die Autorin oder der Autor entscheidet und mergt. Diese Grenzen setzt kanman selbst durch, sie sind nicht nur versprochen. Jedes Review bleibt in den Tokens pro Review des Teams.

Im Team-Chat

Nach einem Review sagt kanman es im Team-Chat in einer Zeile, zum Beispiel „Ich habe den MR web !12 von Bob geprüft: 2 blockierende Befunde“. Der Merge-Request ist ein Link.

Review-Kommentare zu kanmans eigener Arbeit

Wenn Menschen einen Pull- oder Merge-Request prüfen, den kanman geöffnet hat, liest kanman jeden Kommentar und handelt wie ein Kollege: Es behebt Eindeutiges auf demselben Branch, beantwortet Fragen und fragt nach, wenn ein Mensch entscheiden sollte. kanmans eigene Merge-Requests prüft sein unabhängiger Reviewer, bevor sie gemergt werden (siehe Wie kanman seine Arbeit prüft), nie über die Einstellung oben.

Einen Reviewer für kanmans Arbeit anfragen

Mit Eine Person mit Codekenntnis um ein Review bitten in Team > Code-Review bittet kanman für jeden Pull- oder Merge-Request, den es öffnet, einmal eine Person im Team um ein Review. Es wählt jemanden, der zuletzt an den geänderten Dateien gearbeitet hat und Schreibrechte im Repository hat. Es fragt nie die Autorin, seine eigenen Konten oder Bots und fragt niemanden, wenn schon ein Reviewer gesetzt ist. Das ist aus, bis Sie es einschalten, weil kanman dabei Menschen auf Ihrem Code-Host kontaktiert.

GitLab hinter einem VPN

Ein GitLab, das nur Ihr Runner erreicht, kann kanman keine Webhooks schicken. @kanman review und Zuweisungen funktionieren trotzdem: kanman sucht alle paar Minuten über Ihren Runner danach. Jeder MR braucht die Merge-Request-Ereignisse eines Webhooks. Der Code bleibt auf Ihrem Runner: Der Reviewer liest ihn dort, nur die Kommentare verlassen Ihr Netz. Siehe GitLab hinter einem VPN.