Revisión de código de Discourse

:discourse2: Resumen Discourse Code Review permite revisar commits de GitHub en Discourse.
:hammer_and_wrench: Enlace al repositorio https://github.com/discourse/discourse-code-review
:open_book: Guía de instalación Cómo instalar plugins en Discourse

Funciones

¿Qué es?

El plugin Discourse Code Review proporciona una integración bidireccional con repositorios de código de GitHub. Permite a tu equipo revisar commits en un repositorio aprovechando funciones y plugins de Discourse, como asignación, susurros, notificaciones, flujos de trabajo personalizados, etc. Cada commit en un repositorio se convierte en un tema. Las respuestas al tema se reflejan en GitHub. La integración es bidireccional, lo que significa que puedes comentar en Discourse y verlo en GitHub, o comentar en GitHub y verlo en Discourse.

Proporciona un flujo de trabajo muy potente para equipos que necesitan revisar todos los commits en cualquier número de repositorios.

Te permite asegurarte de que varios miembros del equipo estén al tanto de todos los cambios aplicados a los repositorios. Puedes marcar commits para seguimiento, asignar trabajo de revisión, etc.

Nota: Al ver un tema que puede aprobarse, puedes usar la tecla y de tu teclado para aprobar commits más rápido.

¿Puedo verlo en acción?

Discourse utiliza este plugin internamente para hacer seguimiento de repositorios. Puedes ver un ejemplo del lado de Discourse aquí:

En GitHub, el mismo tema se ve así:

Configuración

El plugin se basa en webhooks de GitHub para detectar repositorios y cambios en los repositorios. Para una configuración mínima, debes establecer la siguiente configuración en una cadena secreta.

code review github webhook secret

Una vez establecido en tu repositorio de GitHub, configura un webhook con:

URL de carga (Payload URL): https://YOUR_DISCOURSE/code-review/webhook
Tipo de contenido (Content Type): application/json
Secreto (Secret): el valor de code review github webhook secret
Tipos de eventos (Event Types):

  • Comentarios de commits
  • Comentarios de issues
  • Solicitudes de extracción (Pull requests)
  • Revisiones de solicitudes de extracción (Pull request reviews)
  • Comentarios de revisiones de solicitudes de extracción (Pull request review comments)
  • Empujes (Pushes)

El plugin proporciona los siguientes ajustes de sitio adicionales:

code review api username : GitHub es muy restrictivo con el número de solicitudes de API anónimas que permite; este ajuste te permite usar las claves de la cuenta de un usuario de Discourse para las solicitudes de /comments y /commit. Esto reduce en gran medida la probabilidad de alcanzar los límites de tasa.

code review catch up commits : número de commits para “ponerse al día” y crear temas cuando encuentras un nuevo repositorio.

code review default parent category: elige una categoría padre predeterminada para las categorías creadas por el plugin

code review pending tag: Etiqueta a aplicar a todos los commits no revisados, pending por defecto

code review approved tag: Etiqueta a aplicar a los commits aprobados, approved por defecto

code_review_followup_tag: Etiqueta a aplicar a los commits de seguimiento, follow-up por defecto

code review allow self approval: ¿Se permite al personal aprobar sus propios commits?

code review default mute new categories: Las nuevas categorías creadas por code review están silenciadas para los usuarios por defecto

code review skip duration minutes: Hacer clic en el botón de omitir en un commit evitará que ese commit vuelva a aparecer durante el número de minutos establecido por este ajuste.

CHANGELOG

TODO

Extras

Cómo Discourse usa este plugin

TL;DR - Este plugin fue diseñado para complementar el uso de GitHub por parte del equipo de Discourse para la revisión de código.

Más información

De @sam:

  • Seguimos usando PRs mediante la interfaz de GitHub y nos encanta hacer PRs para muchos cambios. Nada ha cambiado aquí. GitHub es fantástico, nos encanta GitHub. Tienen un excelente flujo de trabajo para los cambios que aún no se han implementado. Sin embargo…

  • El flujo de trabajo de GitHub para los cambios que se han enviado directamente al repositorio es terrible.

  • Review cubre un vacío que simplemente no puede ser cubierto por GitHub hoy en día; nos gustaría que al menos un miembro del equipo revise cada cambio realizado en nuestros diversos repositorios git propiedad de Discourse. Si usamos la interfaz proporcionada por GitHub, nadie estaría nunca permitido hacer nada más que solicitudes de extracción. Esto nos ralentizaría enormemente.

  • Necesitamos la capacidad de comunicarnos en privado sin que todo el mundo lo sepa con respecto a ciertos cambios. Por ejemplo: Mejor desplegar esta increíble corrección en <inserta nombre de la empresa gigante> lo antes posible, ¿puedes encargarte de ello, @sam ?

  • Necesitamos la capacidad de aprobar cambios realizados o solicitar seguimiento, algo que la interfaz de GitHub no ofrece.

  • Necesitamos la capacidad de asignar commits particulares a un usuario. Digamos que @sam hace un commit que contiene algunos errores. Es agradable que podamos asignarle directamente ese commit particular, marcarlo para seguimiento y luego hacer seguimiento de que se haya realizado.

  • Discourse es bastante fantástico en todo este asunto de la conversación, y las pequeñas funciones marcan una diferencia bastante grande; puedo ver cuando la gente está escribiendo. Nunca necesito actualizar las páginas para que aparezcan los cambios. Citar es muy agradable, las cargas de imágenes son buenas, y así sucesivamente.

  • Discourse es muy bueno en el estado de lectura, obtienes garantías muy fuertes de que has leído cada cosa una vez; con GitHub no tengo idea de qué commits leí y cuáles no. Tenemos una eficiencia increíble para hacer frente a la avalancha de información.

Y la lista continúa…

Entonces, review actúa como un complemento de GitHub; usamos GitHub en este momento para hacer frente a los cambios que aún no se han implementado. Y usamos review para manejar adecuadamente los cambios que ya se han implementado.

72 Me gusta

Estoy tratando de entender el propósito de este plugin. Tengo la corazonada de que necesito algo como esto, pero me cuesta ver cómo ayuda con la eficiencia. Cuando alguien aprueba una solicitud de extracción y la fusiona en una rama, ¿qué hay en su proceso que hace que esa aprobación requiera otra aprobación para el commit asociado?

GitHub no ofrece eso en relación con los commits porque se asume que eso ya se ha manejado en la solicitud de extracción. ¿Qué me estoy perdiendo?

¿Se debe a que hay personas en su equipo que pueden aprobar solicitudes de extracción pero no están calificadas para tomar la decisión final sobre ese commit en relación con una versión real? ¿Es el propósito que las solicitudes de extracción se puedan fusionar y revisar rápidamente sin esperar a alguien que tenga la palabra final, con la garantía de que esa persona o equipo revisará el commit antes de que se cree una versión?

¿O es principalmente para apoyar discusiones privadas en repositorios públicos?

Me encantaría tener más información sobre los beneficios de usar este plugin en su flujo de trabajo. ¡Gracias!

Era principalmente una reliquia de flujos de trabajo anteriores en Discourse.

En el pasado, lo usábamos para la aprobación retroactiva de conjuntos de cambios.

Hoy en día, las cosas pasan por los canales de PR, por lo que realmente no usamos mucho el plugin.

1 me gusta