Cómo integrar DangerJS en las tuberías de GoCD

En mi compañía actual, recientemente hemos migrado nuestra infraestructura CI de CircleCI a GoCD. Después de unos meses usando la nueva plataforma de CI, me sentí lo suficientemente cómoda como para aprovecharla. Una de las cosas que estaba planeando era integrar DangerJS, una herramienta increíble para acelerar las revisiones de solicitudes de extracción mediante la realización de verificaciones automáticas configurables en el nuevo código. Qué significa eso? No más tiempo dedicado a escribir comentarios de relaciones públicas como: "Oh, creo que olvidaste X ... Y ... Z ...".

Mi objetivo con este artículo es ayudar a la próxima persona que realice esta misión a mejorar los procesos de revisión de PR y calidad de código de su equipo.

Contexto

He usado los poderes de Danger antes (aunque está integrado con Ruby) y ya sabía que la configuración inicial sería bastante sencilla ... ¡si solo estuviéramos usando CircleCI!

En mi primer intento de integración, intenté buscar en Google "Integrando DangerJS con GoCD" sin suerte. Además, después de leer la documentación de DangerJS, descubrí que no podía utilizar una integración nativa y directa con GoCD.

Eso significaba que no podría integrar fácilmente los cheques de Danger en mi flujo de CI. Así que me quedaban algunas opciones:

  1. Intentando que los desarrolladores incorporen ejecuciones manuales locales de comandos DangerJS;
  2. Construya una tubería específica en (CircleCI / CodeShip / FooBar) para ejecutar solo DangerJS;
  3. Rendirse.

No me gustaban mis opciones, y estaba realmente frustrado después de pasar unas horas en la configuración de Peligro y GoCD. Luego me topé con la sección "Usar el peligro y estar falso en un CI" en los documentos de DangerJS. ¡Eso es! Si puedo fingir estar en un CI en mi máquina local, ¿cuál es la diferencia de falsificar un CI en una máquina GoCD?

Después, solo era cuestión de descubrir cómo emular el mismo comportamiento local dentro de la infraestructura de GoCD.

Primeros pasos

Antes de nada, debe revisar la documentación oficial para configurar y comenzar a usar DangerJS.

Básicamente, lo que necesitas es:

  • Cree su archivo dangerfile.js. Hay algunos ejemplos aquí.
  • Cree una cuenta bot en GitHub / BitBucket para que Danger la use
  • Abra un RP con archivos modificados para verificar sus cambios
  • Ejecute DangerJS localmente contra un enlace PR (el que acaba de abrir)
  • Intenta simular un entorno de CI en tu máquina local

En la siguiente sección, profundizaré en este último paso, ya que es la parte crítica para que DangerJS funcione con GoCD.

Configurar un CI falso en el entorno de GoCD

Primero, si todavía no tiene una tubería GoCD separada para ejecutar solo compilaciones de solicitudes de extracción, le recomiendo encarecidamente que lo haga. Aquí hay una guía si necesita ayuda para configurarlo.

En segundo lugar, después de crear su canal de relaciones públicas, cree un nuevo trabajo solo para Danger:

Ahora, para poder falsificar un CI con Danger, debe establecer un montón de variables de entorno como:

export DANGER_FAKE_CI = "YEP"
export DANGER_TEST_REPO = "nombre de usuario / cambiar nombre"

En la configuración del trabajo de canalización de GoCD, vaya a la pestaña Variables de entorno y configure esas dos variables env reemplazando los marcadores de posición de nombre de usuario / nombre de pila con su propia configuración.

Recomiendo colocar el DANGER_GITHUB_API_TOKEN generado en los primeros pasos de configuración de DangerJS en la sección Variables seguras.

Después de este primer lote de configuraciones, para ejecutar realmente las pruebas de Danger en GoCD, puede usar un script de shell que ejecute los mismos comandos que se utilizan para falsificar un CI en un entorno local. Llamemos a este archivo danger-build.sh.

# danger-build.sh
echo '- - INICIAR PELIGRO VERIFICACIÓN JS -'
echo Prueba contra confirmaciones en PR: $ {GO_SCM_PIPELINE_PR_URL}
DANGER_TEST_PR = $ {GO_SCM_PIPELINE_PR_ID} npx hilo peligro ci
echo ‘- - FIN DE PELIGRO VERIFICACIÓN JS - -‘

Tenga en cuenta que necesitará el nodo, npm / hilo instalado previamente en la máquina GoCD disponible.

¿Notaste esas dos variables GO_SCM? Son la trampa que le permite ejecutar sus verificaciones de peligro dentro de una máquina GoCD.

Preste especial atención a la variable PR_ID, ya que es la que proporciona la referencia de PR para permitir que Danger lea, interprete los cambios y luego escriba sugerencias en la Solicitud de extracción.

En caso de que tenga curiosidad, esas variables de entorno fueron generadas por las máquinas de GoCD. Se pueden evaluar ejecutando el comando / usr / bin / printenv UNIX en una compilación e inspeccionando la salida.

¡Y eso es!

Después de mapear las variables env adecuadas en su script de Shell, las verificaciones de DangerJS comenzarán a ejecutarse en las canalizaciones de GoCD junto a su conjunto de pruebas actual.

Para concluir los pasos:

1. Configure los primeros archivos y configuraciones locales de DangerJS

2. Crear una canalización / trabajo específico en GoCD

3. Descubra y luego asigne las variables de entorno adecuadas dentro de un script de shell para permitir que GoCD ejecute DangerJS

Espero que hayas encontrado útil el tutorial. Si le ha gustado el artículo, comparta con sus colegas desarrolladores y gerentes y ayúdenos a correr la voz.

Para cualquier pregunta, no dude en preguntar en la sección de comentarios.

PD: Danger también tiene muchas opciones de complementos, ¡échales un vistazo!