Revisione del codice Discourse

:discourse2: Riepilogo Discourse Code Review consente di esaminare i commit di GitHub direttamente su Discourse.
:hammer_and_wrench: Link al repository https://github.com/discourse/discourse-code-review
:open_book: Guida all’installazione Come installare i plugin in Discourse

Funzionalità

Di cosa si tratta?

Il plugin Discourse Code Review fornisce un’integrazione bidirezionale con i repository di codice GitHub. Consente al tuo team di esaminare i commit di un repository sfruttando le funzionalità e i plugin di Discourse, come assegnazione, whispers, notifiche, flussi di lavoro personalizzati e così via. Ogni commit in un repository diventa un argomento (topic). Le risposte all’argomento vengono riflesse su GitHub. L’integrazione è bidirezionale, il che significa che puoi commentare su Discourse e vedere il commento su GitHub, oppure commentare su GitHub e vederlo su Discourse.

Offre un flusso di lavoro molto potente per i team che devono esaminare tutti i commit di un qualsiasi numero di repository.

Consente di assicurarsi che più membri del team siano a conoscenza di tutte le modifiche apportate ai repository. Puoi contrassegnare i commit per un seguito, assegnare il lavoro di revisione e altro ancora.

Nota: quando visualizzi un argomento che può essere approvato, puoi utilizzare il pulsante y sulla tua tastiera per approvare i commit più rapidamente.

Posso vederlo in azione?

Discourse mantiene https://review.discourse.org/ questo sito è pubblico e chiunque può registrarsi utilizzando le credenziali di GitHub. Il sito mostra solo un sottoinsieme di funzionalità ai membri non dello staff. Un esempio più completo potrebbe essere:

Su GitHub lo stesso argomento appare così:

Configurazione

Il plugin si basa sui webhook di GitHub per scoprire i repository e le modifiche ai repository. Per una configurazione minima dovrai impostare la seguente impostazione su una stringa segreta.

code review github webhook secret

Una volta impostato sul tuo repository GitHub, configura un webhook con:

URL del payload: https://TUO_DISCOURSE/code-review/webhook
Tipo di contenuto: application/json
Segreto: il valore di code review github webhook secret
Tipi di evento:

  • Commenti ai commit
  • Commenti alle issue
  • Pull request
  • Recensioni delle pull request
  • Commenti alle recensioni delle pull request
  • Push

Il plugin fornisce le seguenti impostazioni aggiuntive del sito:

code review api username: GitHub è molto restrittivo con il numero di richieste API anonime che consente; questa impostazione ti permette di utilizzare le chiavi dell’account di un utente Discourse per le richieste /comments e /commit. Ciò riduce drasticamente le possibilità di raggiungere i limiti di frequenza.

code review catch up commits: numero di commit da “recuperare” e creare come argomenti quando incontri un nuovo repository.

code review default parent category: scegli una categoria padre predefinita per le categorie create dal plugin

code review pending tag: Etichetta da applicare a tutti i commit non revisionati, pending (in attesa) per impostazione predefinita

code review approved tag: Etichetta da applicare ai commit approvati, approved (approvato) per impostazione predefinita

code_review_followup_tag: Etichetta da applicare ai commit da seguire, follow-up (follow-up) per impostazione predefinita

code review allow self approval: Lo staff può approvare i propri commit?

code review default mute new categories: Le nuove categorie create da code review sono disattivate (muted) per gli utenti per impostazione predefinita

code review skip duration minutes: Fare clic sul pulsante di salto su un commit impedirà che quel commit venga visualizzato nuovamente per il numero di minuti impostato da questa impostazione.

CHANGELOG

TODO

Extra

Come Discourse utilizza questo plugin

TL;DR - Questo plugin è stato progettato per integrare l’uso del team di Discourse di GitHub per la revisione del codice.

Maggiori informazioni

Da @sam:

  • Continuiamo a utilizzare le PR tramite l’interfaccia di GitHub e adoriamo fare PR per molte modifiche. Nulla è cambiato qui. GitHub è fantastico, amiamo GitHub. Hanno un eccellente flusso di lavoro per le modifiche che non sono ancora state integrate. Tuttavia…

  • Il flusso di lavoro di GitHub per le modifiche che sono state commitate direttamente nel repository è terribile.

  • La revisione colma una lacuna che semplicemente non può essere colmata con GitHub oggi; vorremmo che almeno un membro del team esaminasse ogni modifica apportata ai nostri vari repository git di proprietà di Discourse. Se dovessimo utilizzare l’interfaccia fornita da GitHub, nessuno potrà mai fare nulla se non pull request. Questo ci rallenterebbe enormemente.

  • Abbiamo bisogno della capacità di comunicare privatamente senza che tutto il mondo lo sappia riguardo a determinate modifiche. Ad esempio: Dobbiamo distribuire questo fantastico fix a <inserisci nome della grande azienda> al più presto, @sam puoi occupartene?

  • Abbiamo bisogno della capacità di approvare le modifiche apportate o richiedere un follow-up, qualcosa che l’interfaccia di GitHub non offre.

  • Abbiamo bisogno della capacità di assegnare commit specifici a un utente. Ad esempio, se @sam fa un commit contenente alcuni errori è bello che possiamo assegnargli direttamente quel particolare commit, segnalarlo per il follow-up e poi tenerne traccia.

  • Discourse è piuttosto fantastico in tutta questa faccenda delle conversazioni, e le piccole funzionalità fanno una grande differenza: vedo quando le persone stanno digitando. Non devo mai aggiornare le pagine per vedere apparire le modifiche. Il citare è molto utile, i caricamenti di immagini sono utili, e così via.

  • Discourse è davvero bravo a gestire lo stato di lettura, hai garanzie molto forti di aver letto ogni singola cosa una volta sola; con GitHub non ho idea di quali commit abbia letto e quali no. Abbiamo un modo incredibilmente efficiente per gestire il flusso incessante di informazioni.

E l’elenco continua…

Quindi la revisione agisce come complemento a GitHub: utilizziamo GitHub al momento per gestire le modifiche che non sono ancora state integrate. E utilizziamo la revisione per gestire correttamente le modifiche che sono già state integrate.

71 Mi Piace

Sto cercando di capire lo scopo di questo plugin. Ho il sospetto che mi serva qualcosa del genere, ma faccio fatica a capire come aiuti l’efficienza. Quando qualcuno approva una pull request e la unisce a un branch, cosa c’è nel tuo processo che rende quell’approvazione richiedere un’altra approvazione per il commit associato?

GitHub non offre questo in relazione ai commit perché si presume che sia già stato gestito nella pull request. Cosa mi sfugge?

È perché ci sono persone nel tuo team che sono autorizzate ad approvare le pull request ma non qualificate a prendere la decisione finale su quel commit in relazione a una release effettiva? Lo scopo è che le pull request possano essere unite e revisionate rapidamente senza aspettare qualcuno che abbia l’ultima parola, con la garanzia che quella persona o quel team esaminerà il commit prima che venga creata una release?

O serve principalmente a supportare discussioni private su repository pubblici?

Mi piacerebbe avere maggiori informazioni sui vantaggi dell’utilizzo di questo plugin nel tuo flusso di lavoro. Grazie!

Era principalmente una reliquia dei flussi di lavoro precedenti di Discourse.

Ai tempi lo usavamo per l’approvazione retroattiva dei set di modifiche.

Oggi le cose passano attraverso i canali PR, quindi non usiamo molto il plugin.

1 Mi Piace