Pipelines Jenkins: comment les utiliser avec Git, en particulier avec plusieurs dépôts Git?

Question

La situation ...

J'ai plusieurs dépôts Git qui sont tous nécessaires pour ma construction. Je développe activement du code sur un, tandis que les autres contiennent du code de bibliothèque que j'utilise. Puisque chaque repo est indépendant, bien sûr, ils ont tous des noms de branches différents.

Pour ma build Jenkins, je voudrais récupérer les versions de code pertinentes de chaque repo, les placer dans les sous-répertoires corrects et construire mon projet. Idéalement, je devrais aussi être capable de faire un clone peu profond (parce que l'un de ces repos est grand), et être capable de faire une extraction clairsemée du seul chemin que je veux. Le Multiple SCMs plugin semblait être l'outil idéal pour le travail. Cependant, il n'est pas en développement actif, et je l'ai vu lancer affirme que d'autres personnes ont parlé.

J'ai vu this question qui répond à la façon d'utiliser le pipeline Jenkins pour ce faire, alors j'ai étudié le pipeline Jenkins. J'ai rapidement découvert à partir du Git Pipeline documentation que son support pour Git pouvait être qualifié de "minimal", ce qui est également vrai pour le reste du concept de Pipeline. (Et c'est avant que nous entrions dans le cauchemar qui remplace une interface utilisateur parfaitement réalisable avec une interface texte seulement cauchemar de maintenance, beaucoup? Ugh!)

Je pourrais également mettre en place des sous-projets Git. Je préférerais ne pas avoir à emprunter cette voie pour résoudre les insuffisances de la dernière version de Jenkins, mais les besoins doivent l'être si c'est la seule solution. Je dirais qu'une solution autre que Jenkins n'est pas vraiment une option, parce que nous utilisons Jenkins dans notre entreprise depuis un certain temps et que nous ne voulons pas vraiment mettre en place quelque chose d'autre.

Answer 1

Je pense que le support git dans Pipeline ne manque pas du tout. Au moins pas plus. Et le pipeline est extrêmement puissant. Certainement pas minime. Peut-être que vous regardez une vieille documentation. Le pipeline déclaratif pourrait encore être considéré comme un peu immature, mais toujours très puissant et facile, et généralement mon choix par défaut à moins que je devrais être un peu plus fou.

La documentation que vous avez publiée pour l'étape de construction git est juste une enveloppe de l'étape checkout scm, qui peut être utilisée pour des opérations git très simples. Ce n'est certainement pas la mesure des options disponibles pour l'utilisation de git dans Jenkins.

En particulier, j'ai un travail de pipeline multibranches qui surveille un repo git. Quand un changement est détecté, le repo est tiré vers le bas, puis je retire une caisse rare d'un autre repo dans un sous-répertoire, puis j'achète un autre repo complet dans un autre répertoire. Je cours des scripts de construction. Zip certaines choses, déployer le fichier zip, puis exécuter des processus ssh à distance pour faire des choses avec les paquets sur le serveur distant.

Dans un pipeline déclarative Je le fais pour une caisse rare:

dir("package/infra") { 
    deleteDir() //start with a clean directory 

    checkout([$class: 'GitSCM', branches: [[name: '*/master']], extensions: [[$class: 'SparceCheckoutPaths', sparseCheckoutPaths: [[path: "my/path/here"]]]], userRemoteConfigs: [[credentialsId: 'asdf-fdsa-werw5-asjksadf-wlfjsdf', url: 'git@github.com:ABC/DEF.git']]]) 

} 

Vous pouvez également faire des clones peu profonds, et toutes sortes de comportement git complexe.

Il est peut-être préférable d'avoir une deuxième version pour vos bibliothèques et de stocker les artefacts construits dans artefact, ou simplement les archiver dans Jenkins. Ensuite, amenez les artefacts à partir d'artefacts ou utilisez le plugin Copier les artefacts. pour les amener d'un autre travail. Mais chaque situation est différente.