Code-Review für Discourse

:discourse2: Zusammenfassung Discourse Code Review ermöglicht die Überprüfung von GitHub-Commits in Discourse.
:hammer_and_wrench: Repository-Link https://github.com/discourse/discourse-code-review
:open_book: Installationsanleitung So installierst du Plugins in Discourse

Funktionen

Was ist das?

Das Discourse Code Review Plugin bietet eine bidirektionale Integration mit GitHub-Code-Repositories. Es ermöglicht deinem Team, Commits in einem Repository unter Nutzung von Discourse-Funktionen und Plugins wie Zuweisung, Flüstern, Benachrichtigung, benutzerdefinierte Workflows usw. zu überprüfen. Jeder Commit in einem Repository wird zu einem Thema. Antworten auf das Thema werden auf GitHub gespiegelt. Die Integration ist bidirektional, was bedeutet, dass du in Discourse kommentieren und es in GitHub sehen kannst oder in GitHub kommentieren und es in Discourse sehen kannst.

Es bietet einen sehr leistungsfähigen Workflow für Teams, die alle Commits in einer beliebigen Anzahl von Repositories überprüfen müssen.

Es ermöglicht dir sicherzustellen, dass mehrere Teammitglieder über alle Änderungen, die an Repositories vorgenommen wurden, informiert sind. Du kannst Commits für eine Nachbearbeitung markieren, Überprüfungsarbeit zuweisen und mehr.

Hinweis: Wenn du ein Thema ansiehst, das genehmigt werden kann, kannst du die y-Taste auf deiner Tastatur verwenden, um Commits schneller zu genehmigen.

Kann ich es in Aktion sehen?

Discourse nutzt dieses Plugin intern zur Verfolgung von Repositories. Du kannst ein Beispiel für die Discourse-Seite hier sehen:

Auf GitHub sieht dasselbe Thema so aus:

Konfiguration

Das Plugin stützt sich auf GitHub-Webhooks, um Repositories und Änderungen an Repositories zu erkennen. Für eine minimale Konfiguration musst du die folgende Einstellung auf einen geheimen String setzen.

code review github webhook secret

Sobald dies in deinem GitHub-Repository festgelegt ist, richte einen Webhook mit den folgenden Parametern ein:

Payload-URL: https://YOUR_DISCOURSE/code-review/webhook
Inhaltstyp: application/json
Geheimnis: der Wert von code review github webhook secret
Ereignistypen:

  • Commit-Kommentare
  • Issue-Kommentare
  • Pull Requests
  • Pull Request Reviews
  • Pull Request Review Kommentare
  • Pushes

Das Plugin bietet die folgenden zusätzlichen Site-Einstellungen:

code review api username : GitHub ist sehr restriktiv bei der Anzahl der erlaubten anonymen API-Anfragen. Diese Einstellung ermöglicht es dir, die Kontoschlüssel eines Discourse-Benutzers für /comments- und /commit-Anfragen zu verwenden. Dies reduziert die Wahrscheinlichkeit, auf Rate-Limits zu stoßen, erheblich.

code review catch up commits : Anzahl der Commits, die „eingeholt“ und für die Themen erstellt werden sollen, wenn du auf ein neues Repository stößt.

code review default parent category: Wähle eine Standard-Elternkategorie für Kategorien, die vom Plugin erstellt werden

code review pending tag: Tag, der auf alle nicht überprüften Commits angewendet wird, standardmäßig pending

code review approved tag: Tag, der auf genehmigte Commits angewendet wird, standardmäßig approved

code_review_followup_tag: Tag, der auf Commits für die Nachbearbeitung angewendet wird, standardmäßig follow-up

code review allow self approval: Darfen Mitarbeiter eigene Commits genehmigen?

code review default mute new categories: Neue Kategorien, die von Code Review erstellt werden, sind für Benutzer standardmäßig stummgeschaltet

code review skip duration minutes: Das Klicken auf die Schaltfläche „Überspringen“ bei einem Commit verhindert, dass dieser Commit für die Anzahl der Minuten, die durch diese Einstellung festgelegt ist, erneut angezeigt wird.

CHANGELOG

TODO

Extras

Wie Discourse dieses Plugin verwendet

TL;DR – Dieses Plugin wurde entwickelt, um die Nutzung von GitHub durch das Discourse-Team für die Code-Überprüfung zu ergänzen.

Weitere Informationen

Von @sam:

  • Wir nutzen weiterhin PRs über die GitHub-UI und lieben es, PRs für viele Änderungen zu erstellen. Hier hat sich nichts geändert. GitHub ist fantastisch, wir lieben GitHub. Sie haben einen hervorragenden Workflow für Änderungen, die noch nicht eingelandet sind. Allerdings…

  • Der Workflow von GitHub für Änderungen, die direkt committet wurden, ins Repository ist schrecklich.

  • Review füllt eine Lücke, die mit GitHub heute schlicht nicht gefüllt werden kann. Wir möchten, dass mindestens ein Teammitglied jede Änderung in unseren verschiedenen von Discourse verwalteten Git-Repos überprüft. Wenn wir die von GitHub bereitgestellte UI nutzen, wird niemandem jemals erlaubt sein, irgendetwas anderes als Pull Requests zu tun. Dies würde uns enorm verlangsamen.

  • Wir benötigen die Möglichkeit, privat zu kommunizieren, ohne dass die ganze Welt davon weiß, was bestimmte Änderungen betrifft. Zum Beispiel: Wir sollten dieses tolle Fix so schnell wie möglich für <insert giant company name> bereitstellen, @sam, kannst du dich darum kümmern?

  • Wir benötigen die Möglichkeit, Änderungen zu genehmigen oder Nachbearbeitung anzufordern. Das bietet die GitHub-UI nicht.

  • Wir benötigen die Möglichkeit, bestimmte Commits einem Benutzer zuzuweisen. Sagen wir, @sam erstellt einen Commit, der einige Fehler enthält. Es ist schön, dass wir ihm diesen bestimmten Commit direkt zuweisen, ihn für die Nachbearbeitung markieren und dann die Nachbearbeitung verfolgen können.

  • Discourse ist ziemlich fantastisch bei dem ganzen Gesprächsthema, und die kleinen Funktionen machen einen ziemlich großen Unterschied. Ich kann sehen, wenn Leute tippen. Ich muss nie Seiten aktualisieren, damit Änderungen auftauchen. Zitate sind wirklich schön, Bild-Uploads sind schön, und so weiter.

  • Discourse ist wirklich gut im Lesen-Zustand. Du erhältst sehr starke Garantien, dass du alles genau einmal liest. Bei GitHub habe ich keine Ahnung, welche Commits ich gelesen habe und welche nicht. Wir haben ein unglaublich effizientes System, um mit dem Feuerstrahl an Informationen umzugehen.

Und die Liste geht weiter…

Also wirkt Review als Ergänzung zu GitHub. Wir nutzen GitHub im Moment, um mit Änderungen umzugehen, die noch nicht eingelandet sind. Und wir nutzen Review, um Änderungen, die bereits eingelandet sind, angemessen zu behandeln.

72 „Gefällt mir“

Ich versuche, den Zweck dieses Plugins zu verstehen. Ich habe eine Ahnung, dass ich so etwas brauche, aber ich kann nicht erkennen, wie es zur Effizienz beiträgt. Wenn jemand eine Pull-Anfrage genehmigt und sie in einen Branch merged, was ist es an Ihrem Prozess, das diese Genehmigung eine weitere Genehmigung für den zugehörigen Commit erfordert?

[Zitat=“Discourse, Beitrag:1, Thema:103142”]
Wir benötigen die Möglichkeit, vorgenommene Änderungen zu genehmigen oder Nachverfolgungen anzufordern, dies bietet die GitHub-Benutzeroberfläche nicht.
[/Zitat]

GitHub bietet das in Bezug auf Commits nicht an, weil davon ausgegangen wird, dass dies bereits in der Pull-Anfrage behandelt wurde. Was übersehe ich?

Liegt es daran, dass es in Ihrem Team Personen gibt, die Pull-Anfragen genehmigen dürfen, aber nicht qualifiziert sind, die endgültige Entscheidung über diesen Commit in Bezug auf eine tatsächliche Veröffentlichung zu treffen? Ist der Zweck, dass Pull-Anfragen schnell zusammengeführt und überprüft werden können, ohne auf jemanden zu warten, der das letzte Wort hat, mit der Zusicherung, dass diese Person oder dieses Team den Commit vor der Erstellung einer Version überprüft?

Oder dient es hauptsächlich der Unterstützung privater Diskussionen in öffentlichen Repos?

Ich würde gerne mehr Einblick in die Vorteile der Verwendung dieses Plugins in Ihrem Workflow erhalten. Danke!

Es war hauptsächlich ein Relikt früherer Arbeitsabläufe bei Discourse.

Früher haben wir es für die nachträgliche Genehmigung von Änderungssätzen verwendet.

Heutzutage laufen die Dinge über PR-Kanäle, sodass wir das Plugin nicht mehr so oft verwenden.

1 „Gefällt mir“