Revisión de código de Discourse

:discourse2: Resumen Discourse Code Review permite revisar los 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

Funcionalidades

¿Qué es?

El plugin Discourse Code Review proporciona una integración bidireccional con los repositorios de código de GitHub. Permite a tu equipo revisar los commits de un repositorio aprovechando las características y plugins de Discourse, como asignar, whispers (mensajes privados), notificaciones, flujos de trabajo personalizados, etc. Cada commit realizado 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 de 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 tareas de revisión y más.

Nota: Al ver un tema que puede ser aprobado, puedes usar el botón y de tu teclado para aprobar commits más rápido.

¿Puedo verlo en acción?

Discourse mantiene https://review.discourse.org/ Este sitio es público y cualquiera puede registrarse usando credenciales de GitHub. El sitio solo muestra un subconjunto de características a los miembros que no son del personal. Un ejemplo más completo podría ser:

En GitHub, el mismo tema se ve así:

Configuración

El plugin depende de los webhooks de GitHub para descubrir repositorios y cambios en los mismos. Para una configuración mínima, deberás establecer la siguiente configuración con una cadena secreta.

code review github webhook secret

Una vez establecido en la configuración de tu repositorio de GitHub, configura un webhook con:

URL de la carga útil: https://YOUR_DISCOURSE/code-review/webhook
Tipo de contenido: application/json
Secreto: el valor de code review github webhook secret
Tipos de eventos:

  • Comentarios de commits
  • Comentarios de issues
  • Pull requests
  • Revisiones de pull requests
  • Comentarios de revisiones de pull requests
  • Envíos (Pushes)

El plugin proporciona los siguientes ajustes adicionales del sitio:

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 cuenta de un usuario de Discourse para las solicitudes de /comments y /commit. Esto reduce considerablemente las posibilidades de alcanzar los límites de frecuencia.

code review catch up commits: número de commits a “poner al día” y crear temas cuando te encuentres con un nuevo repositorio.

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

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

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

code_review_followup_tag: Etiqueta para 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 impedirá que ese commit vuelva a aparecer durante el número de minutos establecidos en este ajuste.

REGISTRO DE CAMBIOS

PENDIENTES

Extras

Cómo Discourse utiliza este plugin

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

Más información

De @sam:

  • Todavía usamos PRs (Pull Requests) usando 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 integrado. Sin embargo…

  • El flujo de trabajo de GitHub para los cambios que se han confirmado directamente en el repositorio es terrible.

  • La revisión llena un vacío que simplemente no se puede llenar con GitHub hoy en día; nos gustaría que al menos un miembro del equipo revisara cada cambio realizado en nuestros diversos repositorios git propiedad de Discourse. Si vamos a usar la interfaz proporcionada por GitHub, nadie nunca tendrá permitido hacer nada más que pull requests. Esto nos ralentizaría enormemente.

  • Necesitamos la capacidad de comunicarnos de forma privada sin que todo el mundo lo sepa con respecto a ciertos cambios. Por ejemplo: Será mejor que despleguemos esta increíble corrección en <insert giant company name> lo antes posible, @sam, ¿puedes encargarte de ello?

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

  • Necesitamos la capacidad de asignar commits específicos a un usuario. Digamos que @sam hace un commit que contiene algunos errores. Es bueno que podamos asignarle directamente ese commit en particular, marcarlo para seguimiento y luego hacer un seguimiento de que se está llevando a cabo.

  • Discourse es bastante fantástico en toda esta cosa de las conversaciones, y las pequeñas características marcan una gran diferencia; puedo ver cuándo la gente está escribiendo. Nunca necesito actualizar las páginas para que aparezcan los cambios. La cita es realmente agradable, las cargas de imágenes son agradables, y así sucesivamente.

  • Discourse es realmente bueno con el estado de lectura; tienes garantías muy fuertes de que lees cada cosa una sola vez; con GitHub no tengo idea de qué commits he leído y cuáles no. Tenemos una forma increíblemente eficiente de hacer frente al torrente de información.

Y la lista continúa…

Así que la revisión actúa como complemento de GitHub; en este momento usamos GitHub para manejar los cambios que aún no se han integrado. Y usamos la revisión para manejar adecuadamente los cambios que ya se han integrado.

71 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