ChatGPT-Dokumentation
Deutsch
Kontakt goolvyouyou@gmail.com

GitLab-Merge-Requests mit Codex prüfen

Richten Sie Code-Review für GitLab-Merge-Requests ein und fordern Sie Reviews mit @codex review an.

Nutzen Sie Codex Code-Review, um GitLab-Merge-Requests einer weiteren aussagekräftigen Prüfung zu unterziehen. Codex prüft den Diff des Merge-Requests, befolgt die Vorgaben Ihres Repositorys und veröffentlicht ein standardmäßiges GitLab-Code-Review mit Fokus auf schwerwiegende Probleme.

Die GitLab-Unterstützung befindet sich in der Betaphase und ist in allen ChatGPT-Tarifen verfügbar. Die Codex- Integration wird in Codex Cloud ausgeführt. GitHub-ähnliche Repository-Steuerelemente in der Desktop-App, wie Create pull request, sind in dieser Beta nicht enthalten.

Bevor Sie beginnen

Stellen Sie Folgendes sicher:

Codex Code-Review einrichten

GitLab-Verbindung und Codex-Review-Identität einrichten

Verbinden Sie für GitLab.com Ihr GitLab-Konto in Codex, nachdem Sie GitLab mit ChatGPT verbunden haben. Bei selbstverwaltetem oder Dedicated GitLab sollten alle Reviewer die Verbindung herstellen, nachdem die Workspace-Admin-Vorlage veröffentlicht wurde.

Öffnen Sie für selbstverwaltetes oder Dedicated GitLab Codex Cloud → Settings → Connectors. Ein Workspace-Admin kann Codex ein Dienstkonto erstellen lassen oder ein vorhandenes persönliches Zugriffstoken eines Dienstkontos speichern.

Konto von Codex erstellen lassen

Wählen Sie unter Codex Cloud → Settings → Connectors die App für Ihren selbstverwalteten oder Dedicated-GitLab-Host aus → wählen Sie Set up service account → Create a service account. Der Workspace-Admin, der die Einrichtung abschließt, muss über Administratorzugriff auf die GitLab-Instanz verfügen. Wählen Sie entweder Selected groups oder Selected projects only aus, legen Sie dann fest, wo Codex eingesetzt werden soll, und erstellen Sie das Konto. Die Gruppenoption gewährt Developer-Zugriff auf jede ausgewählte Gruppe, der an ihre Projekte und Untergruppen vererbt wird; die Projektoption gewährt Developer- Zugriff nur auf die einzeln ausgewählten Projekte. Codex erstellt das Instanz-Dienstkonto für den ChatGPT Codex Connector mit einem persönlichen Zugriffstoken mit dem api-Scope.

Vorhandenes Konto verwenden

Erstellen oder wählen Sie in GitLab ein Dienstkonto aus und gewähren Sie ihm Developer-Zugriff nur in den Gruppen oder Projekten, in denen Codex eingesetzt werden soll. Wählen Sie auf der Seite Service accounts das Konto aus → Manage access tokens → Add new token, um ein persönliches Zugriffstoken zu erstellen, das über den api-Scope und ein mindestens 30 Tage in der Zukunft liegendes Ablaufdatum verfügt. Wählen Sie anschließend in Codex Use an existing service account, fügen Sie das Token ein und wählen Sie Save token. Das Token wird beim Speichern verschlüsselt und danach nie wieder angezeigt.

Token des Dienstkontos verwalten

Workspace-Admins können das Dienstkonto unter Codex Cloud → Settings → Connectors verwalten. Bei einem von Codex erstellten Konto können Admins das aktuelle Token widerrufen und ein neues generieren. Bei einem vorhandenen Konto können Admins das gespeicherte Token in Codex ersetzen oder entfernen und es bei Bedarf separat in GitLab widerrufen. Codex kann erst auf GitLab-Aktivitäten reagieren, wenn ein gültiges Token konfiguriert ist.

Festlegen, wie GitLab-Aktivitäten Codex erreichen

Projektumgebung für Programmieraufgaben oder eine projektspezifische Einrichtung erstellen

Wählen Sie unter Codex Cloud → Settings → Environments das GitLab-Projekt aus und erstellen Sie eine Projektumgebung, wenn Codex Code für dieses Projekt schreiben oder ausführen soll – beispielsweise um Dateien zu bearbeiten, Änderungen zu committen oder Aktualisierungen in einen Merge-Request-Branch zu pushen – oder wenn ein Review von projektspezifischen Secrets, Netzwerkzugriff oder Einrichtungsbefehlen abhängt.

Für GitLab.com ist eine Projektumgebung außerdem erforderlich, um Codex-Reviews zu aktivieren.

Aktivieren Sie beim Erstellen der Umgebung Enable Codex activity from GitLab, um den Projekt-Webhook zu installieren, der Merge-Request-, Kommentar- und Issue- Ereignisse an Codex übermittelt. Das Erstellen des Projekt-Webhooks erfordert Maintainer- oder Owner- Zugriff, Administratorzugriff oder eine benutzerdefinierte Rolle, mit der Projekt- Webhooks verwaltet werden können. Signierte Projekt- und Gruppen-Webhooks erfordern GitLab 19.0 oder neuer. Prüfen Sie bei selbstverwaltetem GitLab 19.0, ob das Feature-Flag webhook_signing_token aktiviert ist; es ist standardmäßig aktiviert und wurde in GitLab 19.1 entfernt.

Aktivitäten für Codex-Reviews in Projekten einer GitLab-Gruppe aktivieren

Bei selbstverwaltetem oder Dedicated GitLab können Workspace-Admins Environments → GitLab activity → Manage groups öffnen, um Codex-Reviews für eine Gruppe und ihre Untergruppen zu aktivieren. Codex installiert einen Gruppen-Webhook, der Projekte in der gesamten Gruppe abdeckt. Der verbundene GitLab-Benutzer muss Group Owner sein, und Gruppen-Webhooks erfordern GitLab Premium oder Ultimate sowie GitLab 19.0 oder neuer.

Gruppenaktivitäten ermöglichen Code-Reviews, erstellen jedoch keine Projektumgebungen. Um von GitLab ausgelöste Programmieraufgaben auszuführen, etwa Dateien zu bearbeiten, Befehle auszuführen, Änderungen zu committen oder Aktualisierungen in einen Merge-Request zu pushen, erstellen Sie eine Projektumgebung.

Code-Review-Richtlinien konfigurieren

Konfigurieren Sie Code-Review-Richtlinien in den Codex-Review-Einstellungen. Wählen Sie die Repository-Richtlinie aus: Review my MRs, Review team MRs, Review all MRs oder Follow personal. Legen Sie anschließend fest, wann Reviews ausgeführt werden: On MR open, On every push oder Smart Trigger (Experimental). Repository-Einstellungen können persönliche Standardwerte überschreiben.

Codex-Review anfordern

  1. Erwähnen Sie in einem Merge-Request-Kommentar @codex review.
  2. Warten Sie, bis Codex reagiert (👀) und ein Review veröffentlicht.

Codex veröffentlicht GitLab-Diskussionen und -Notizen im Merge-Request, genau wie ein Teammitglied. Standardmäßig können manuell angeforderte Reviews Befunde der Prioritäten P0, P1 und P2 enthalten, während automatische Reviews sich auf Befunde der Prioritäten P0 und P1 konzentrieren.

Automatische Reviews aktivieren

Um geeignete Merge-Requests automatisch zu prüfen, aktivieren Sie Automatic reviews in den Codex-Einstellungen, wählen Sie die GitLab-Repository-Richtlinie und anschließend einen Auslöser aus: On MR open, On every push oder Smart Trigger (Experimental). Codex wird ohne einen @codex review-Kommentar ausgeführt, wenn das Merge-Request-Ereignis dieser Richtlinie und diesem Auslöser entspricht.

GitLab-Aktivitäten müssen über einen Projekt-Webhook oder den Gruppen-Webhook einer übergeordneten Gruppe aktiviert sein. Bei selbstverwaltetem oder Dedicated GitLab muss das konfigurierte Dienstkonto außerdem Schreibzugriff auf das Projekt haben. Codex verwendet eine konfigurierte Projektumgebung, sofern vorhanden. Wenn eine übergeordnete Gruppe Aktivitäten bereits aktiviert, erben untergeordnete Projekte diese Abdeckung.

Anpassen, was Codex prüft

Codex durchsucht Ihr Repository nach AGENTS.md-Dateien und befolgt die anwendbaren Code-Review-Regeln. Fügen Sie der Datei, die dem von den Regeln erfassten Code am nächsten liegt, einen ## Code Review Rules-Abschnitt hinzu. Verwenden Sie bei Bedarf ###-Überschriften, um zusammengehörige Prüfungen zu gruppieren.

Ein Dienst für die Berichterstattung zu Experimenten kann beispielsweise verhindern, dass Verhalten nach einer Exposition eine Vergleichskohorte verändert:

## Code Review Rules

### Experiment cohorts

- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

Legen Sie Repository-weite Regeln in der AGENTS.md im Stammverzeichnis und dienstspezifische Regeln in einer verschachtelten Datei wie services/experiment_reporting/AGENTS.md ab. Codex wendet die Vorgaben aus dem Stammverzeichnis sowie die spezifischeren Vorgaben an, die für jede geänderte Datei gelten, sodass nicht zusammenhängende Änderungen keinen dienstspezifischen Kontext mitführen müssen.

Beginnen Sie mit zwei oder drei präzisen Regeln, die Prüfungen abbilden, welche Reviewer häufig erläutern. Sinnvolle Regeln:

  • Auf folgenreiches, Repository-spezifisches Verhalten konzentrieren. Beschreiben Sie die Kompatibilitätsbeschränkung, Datengrenze oder unsichere Nebenwirkung, die gemeldet werden soll, und warum sie relevant ist.
  • Sicheren Pfad oder Ausnahme angeben. Geben Sie Codex ausreichend Kontext, um ein tatsächliches Problem von erwartetem Verhalten zu unterscheiden.
  • Regeln klar eingrenzen und beständig halten. Bevorzugen Sie Ergebnisse gegenüber Funktionsnamen, die sich ändern können, und platzieren Sie Vorgaben nahe bei dem Code, für den sie gelten.
  • Mechanische Prüfungen der CI überlassen. Nehmen Sie Formatierung, Linting und andere deterministische Prüfungen nicht in Review-Regeln auf.

Öffnen Sie einen repräsentativen Merge-Request und fordern Sie mit @codex review ein Review an. Verfeinern Sie die Regeln anhand der angezeigten Befunde und Rückmeldungen und grenzen Sie Vorgaben, die Störmeldungen verursachen, enger ein oder entfernen Sie sie.

Code-Review-Regeln dienen Codex als Leitlinie; sie ersetzen weder Tests noch Branch-Schutzregeln oder erforderliche Genehmigungen.

Für einen einmaligen Schwerpunkt fügen Sie ihn Ihrem Merge-Request-Kommentar hinzu:

@codex review for issues in the database migration

Auf Review-Befunde reagieren

Das Beheben von Review-Befunden erfordert eine konfigurierte Projektumgebung; Gruppenaktivitäten allein unterstützen Reviews, können aber keine Programmieraufgaben ausführen. Wenn das Projekt über eine Umgebung verfügt, bitten Sie Codex, ein Problem im selben Merge-Request zu beheben, indem Sie einen weiteren Kommentar hinterlassen:

@codex fix the P1 issue

Codex startet einen Cloud-Chat mit dem Merge-Request als Kontext und kann einen Fix zurück in den Branch pushen, wenn die erforderliche Berechtigung vorliegt.

Codex andere Aufgaben zuweisen

Andere Programmieraufgaben erfordern ebenfalls eine konfigurierte Projektumgebung; Gruppenaktivitäten allein unterstützen Reviews. Wenn Sie @codex in einem Kommentar mit etwas anderem als review erwähnen, startet Codex einen Cloud-Chat mit Ihrem Merge-Request als Kontext.

@codex fix the CI failures

Fehlerbehebung bei Code-Reviews

Wenn Codex nicht reagiert oder kein Review veröffentlicht:

  • Prüfen Sie, ob die vorgesehene GitLab-App ausgewählt wurde; wenn Sie eine projektspezifische Einrichtung verwenden, prüfen Sie, ob das Projekt über die vorgesehene Codex-Cloud-Umgebung verfügt.
  • Prüfen Sie die Aktivitäten für das Projekt oder eine übergeordnete Gruppe. Öffnen Sie in GitLab Webhooks → Recent events und vergewissern Sie sich, dass Merge-Request- und Notizübermittlungen erfolgreich sind.
  • Prüfen Sie bei selbstverwaltetem oder Dedicated GitLab, ob der Projekt- oder Gruppen-Webhook signiert, die SSL-Überprüfung aktiviert und mindestens GitLab 19.0 auf der Instanz installiert ist. Prüfen Sie bei selbstverwaltetem GitLab 19.0, ob das Feature-Flag webhook_signing_token aktiviert ist; reparieren Sie Hooks, die nach Fehlern automatisch deaktiviert wurden.
  • Prüfen Sie bei selbstverwaltetem oder Dedicated GitLab, ob das persönliche Zugriffstoken eines vorhandenen Dienstkontos aktiv ist und über den api-Scope verfügt. Falls Codex das Dienstkonto erstellt hat, prüfen Sie, ob es in den Codex-Connector-Einstellungen ordnungsgemäß konfiguriert und das Projekt oder die Gruppe aktiviert ist.
  • Prüfen Sie bei selbstverwaltetem oder Dedicated GitLab, ob das Workspace-Dienstkonto – nicht nur der verbundene GitLab-Benutzer – über Developer-Zugriff auf das Projekt oder eine übergeordnete Gruppe verfügt, damit Codex Reviews und Reaktionen veröffentlichen kann. Die Mitgliedschaft wird vererbt; Aktivitäten und Dienstkontozugriff sind voneinander unabhängig.
  • Prüfen Sie, ob Code review oder Automatic reviews aktiviert ist und der MR der Repository-Richtlinie sowie dem Auslöser entspricht.
  • Verwenden Sie @codex review.