Comment intégrer DangerJS dans les pipelines GoCD

Dans ma société actuelle, nous avons récemment migré notre infra CI de CircleCI vers GoCD. Après quelques mois d'utilisation de la nouvelle plate-forme CI, j'étais suffisamment à l'aise pour en prendre une décision. Une des choses que je prévoyais était d'intégrer DangerJS - un outil formidable pour accélérer les révisions des demandes d'extraction en effectuant des vérifications automatiques configurables sur le nouveau code. Qu'est-ce que ça veut dire? Plus de temps passé à écrire des commentaires de relations publiques comme: «Oh, je crois que tu as oublié X… Y… Z…».

Mon objectif avec cet article est d’aider la prochaine personne à poursuivre cette mission à améliorer les processus de révision de la qualité du code et des relations publiques de leur équipe.

Le contexte

J’avais déjà utilisé les pouvoirs de Danger auparavant (bien que intégré à Ruby) et je savais déjà que la configuration initiale serait assez simple… si seulement nous utilisions encore CircleCI!

Lors de ma première tentative d'intégration, j'ai essayé de chercher «Intégration de DangerJS avec GoCD» dans Google, sans succès. De plus, après avoir lu la documentation de DangerJS, j’ai constaté qu’il n’existait aucune intégration simple avec GoCD en langage natif que je pourrais utiliser.

Cela signifiait que je ne pouvais pas intégrer facilement les contrôles Danger dans mon flux de CI. Il me restait donc quelques options:

  1. Essayer de faire en sorte que les développeurs intègrent des exécutions manuelles locales des commandes DangerJS;
  2. Construisez un pipeline spécifique dans (CircleCI / CodeShip / FooBar) pour exécuter uniquement DangerJS;
  3. Abandonner.

Je n’aimais aucune de mes options et j’étais vraiment frustré après quelques heures passées dans les réglages Danger et GoCD. Ensuite, je suis tombé sur la section «Utiliser le danger et être un faux sur un CI» dans la documentation de DangerJS. C'est ça! Si je peux simuler le fait d’être sur un CI sur ma machine locale, quelle est la différence avec une simulation de CI sur une machine GoCD?

Ensuite, il s’agissait simplement de trouver le moyen de reproduire le même comportement local dans l’infra de GoCD.

Premiers pas

Avant toute chose, vous devez parcourir la documentation officielle pour pouvoir configurer et commencer à utiliser DangerJS.

En gros, vous avez besoin de:

  • Créez votre fichier dangerfile.js. Il y a quelques exemples ici.
  • Créer un compte bot sur GitHub / BitBucket pour Danger à utiliser
  • Ouvrez un PR avec les fichiers modifiés pour vérifier vos modifications
  • Exécutez DangerJS localement sur un lien de relations publiques (celui que vous venez d'ouvrir)
  • Essayez de simuler un environnement CI sur votre machine locale

Dans la section suivante, je vais aller plus loin dans cette dernière étape car c’est la partie critique de faire en sorte que DangerJS fonctionne avec GoCD.

Configuration d’un faux CI dans l’environnement de GoCD

Premièrement, si vous n’avez toujours pas de pipeline GoCD détaché pour exécuter uniquement les générations Pull Requests, je vous le recommande vivement. Voici un guide si vous avez besoin d’aide pour le configurer.

Deuxièmement, après avoir créé votre pipeline de relations publiques, créez un nouveau travail juste pour Danger:

Désormais, pour pouvoir simuler un élément de configuration en utilisant Danger, vous devez définir un ensemble de variables d’environnement telles que:

export DANGER_FAKE_CI = "YEP"
export DANGER_TEST_REPO = "nom d'utilisateur / nom"

Dans les paramètres de la tâche de pipeline du GoCD, accédez à l’onglet Variables d’environnement et définissez ces deux variables d’environnement en remplaçant les espaces réservés nom d'utilisateur / nom générique par vos propres paramètres.

Je vous recommande de placer le DANGER_GITHUB_API_TOKEN généré lors des premières étapes de configuration de DangerJS dans la section Variables sécurisées.

Après ce premier lot de configurations, vous pouvez utiliser un script shell qui exécute les tests de Danger dans GoCD et exécute les mêmes commandes que celles utilisées pour simuler un CI dans un environnement local. Appelons ce fichier danger-build.sh.

# danger-build.sh
echo '- - DÉMARRER DANGER JS VÉRIFICATION -'
echo Test contre les validations sur le RP: $ {GO_SCM_PIPELINE_PR_URL}
DANGER_TEST_PR = $ {GO_SCM_PIPELINE_PR_ID} npx fil danger ci
echo '- - FIN DE LA DANGER JS VERIFICATION - -'

Veuillez noter que vous aurez besoin de node, npm / yarn préalablement installé sur la machine disponible pour GoCD.

Avez-vous remarqué ces deux variables GO_SCM? Ce sont les pièges qui vous permettent d’effectuer vos vérifications de danger à l’intérieur d’une machine GoCD.

Portez une attention particulière à la variable PR_ID, car c’est celle qui fournit la référence PR pour permettre à Danger de lire, d’interpréter les modifications, puis d’écrire des suggestions dans la demande d’enregistrement.

Au cas où vous seriez curieux, ces variables d’environnement ont été générées par les machines de GoCD. Ils peuvent être évalués en exécutant la commande UNIX / usr / bin / printenv dans une version et en inspectant la sortie.

Et c'est tout!

Après avoir mappé les variables d’env appropriées dans votre script Shell, les vérifications DangerJS commencent à s’exécuter dans les pipelines de GoCD à côté de votre suite de tests actuelle.

Pour conclure les étapes:

1. Configurez les premiers fichiers et paramètres DangerJS locaux

2. Créer un pipeline / job spécifique dans GoCD

3. Découvrez et ensuite mappez les variables d'environnement appropriées dans un script shell pour permettre à GoCD d'exécuter DangerJS.

J'espère que vous avez trouvé la procédure pas à pas utile. Si vous avez apprécié l'article, partagez-le avec vos collègues développeurs et gestionnaires et aidez-nous à passer le mot.

Pour toute question, n'hésitez pas à demander dans la section commentaires!

PS: Danger a aussi beaucoup d’options de plugins, allez les voir!