web-dev-qa-db-fra.com

Jenkins Pipeline: est-il possible d'éviter les achats multiples?

J'ai transféré quelques anciens travaux Jenkins vers de nouveaux en utilisant la fonction pipeline afin de pouvoir intégrer la configuration Jenkins dans les référentiels git. Cela fonctionne bien, mais je me demande s’il est possible de réduire le nombre de caisses lors de la construction.

Installer

  • J'ai un travail multibranches Jenkins qui est lié à mon référentiel git

  • J'ai un Jenkinsfile dans mon dépôt git

    #!groovy
node {

  stage 'Checkout'
  checkout scm

  // build project
  stage 'Build'
  ...
}

Problème

Lorsque j'appuie sur ma branche distante BRANCH_1, le travail multibranches jenkins est déclenché et ma compréhension est que les étapes suivantes se produisent:

  • le travail multibranches crée un git fetch pour l'indexation de la branche et déclenche le travail correspondant à ma branche distante: BRANCH_1_job
  • BRANCH_1_job crée un git checkout pour récupérer le fichier Jenkins de la branche déclenchée.
  • le fichier Jenkins est exécuté et crée lui-même un checkout scm. Si je ne le fais pas, je ne peux pas construire mon projet car aucune source n'est disponible.

Donc, pour construire ma branche, je me retrouve avec un git fetch et deux git checkout.

Des questions

  • Est-ce que je comprends bien le processus? Ou ai-je raté quelque chose?
  • Est-il possible de réduire le nombre de git checkout? Quand je vérifie les exemples officiels , ils font tous une première commande. Personnellement, je pense que je ne suis pas obligé de le faire, car le travail de jenkins devait déjà faire une vérification pour récupérer le fichier Jenkins (donc mes sources doivent être ici d'une manière ou d'une autre).
  • Ne pensez-vous pas que ces extractions multiples peuvent entraîner de mauvaises performances dès que le dépôt git contient un grand nombre de références?

Merci à tous

gitjenkinsjenkins-pipeline
15
Bastien

Avec git, Jenkins doit effectuer deux opérations de contrôle: l'une pour que le fichier Jenkins sache quoi exécuter dans le travail, puis un autre achat du contenu du référentiel à des fins de construction. depuis le repo, mais git ne permet pas de récupérer un seul fichier. Par conséquent, le double contrôle ne peut pas être évité avec Plain Git en utilisant le plugin Multibranch.

Si vous hébergez git sur Bitbucket ou GitHub, vous évitez la double vérification en utilisant leurs plugins Jenkins spécifiques au lieu du plugin multibranche.

Voir le site de plugins Jenkins pour Bitbucket et GitHub plugins en conséquence.

Ces plugins utilisent l'API REST du fournisseur Git respectif pour charger le fichier Jenkins unique. Donc, techniquement, vous avez toujours un double contrôle, mais le premier est un simple appel REST permettant de télécharger un seul fichier, plutôt que de procéder à un contrôle git complet complet du référentiel.

5
fdd

Je l'ai rencontré plusieurs fois et la solution robuste qui m'a été proposée consistait à définir un minuscule "script de lancement" dans le travail lui-même (sans source SCM), qui vérifie la révision de source correcte et charge le pipeline à partir des sources.

Si vous utilisez le plug-in DSL pour généraliser votre travail, vous définissez le pipeline de la manière suivante:

pipelineJob("myjob") {
  ...
  definition {
    cps {
      script('''
        node {
          checkout scm
          load("path/to/script.groovy")
        }
      ''')
    }
  }
}

Si vous configurez le travail manuellement à l'aide de l'écran "Configurer" de jenkins, il en va de même si vous choisissez "Script de pipeline" au lieu de "Script de pipeline à partir de SCM" et à la copie du petit script d'extraction et de chargement à l'intérieur de la boîte.

Cela permet de découpler le démarrage du pipeline du SCM réel et vous permet de procéder à une extraction et de disposer à la fois de la définition du pipeline et des sources à générer. Ce n’est pas la plus belle des approches, mais fait le travail bien.

0
Tareq Sha