web-dev-qa-db-fra.com

Dans Jenkins, comment extraire un projet dans un répertoire spécifique (à l'aide de GIT)

Désolé pour le style 'svn' - nous sommes en train de migrer de SVN vers GIT (y compris notre environnement CI Jenkins).

Ce dont nous avons besoin, c'est de pouvoir faire en sorte que Jenkins récupère (ou devrais-je dire, cloner?) Le projet GIT (référentiel?) Dans un répertoire spécifique. Nous avons essayé quelques réflexions magiques mais il n’était pas évident de les comprendre et de les utiliser avec succès.

De plus, si dans le même projet Jenkins, nous devons extraire plusieurs référentiels GitHub privés dans plusieurs répertoires distincts sous une racine de projet, comment pouvons-nous le faire s'il vous plaît?

Nous avons installé le plugin GitHub. J'espère que nous avons bien formulé les choses.

55
viebel

La valeur par défaut git plugin pour Jenkins fait très bien son travail.

Après avoir ajouté un nouveau référentiel git (configuration du projet> Gestion du code source > cochez l'option GIT), naviguez vers le bas des paramètres du plug-in, juste au-dessus Navigateur de référentiel région. Il devrait y avoir un bouton avancé . Après avoir cliqué dessus, un nouveau formulaire doit apparaître, avec une valeur décrite sous la forme Sous-répertoire local du référentiel (facultatif) . Définir ceci à folder obligera le plugin à extraire le référentiel dans le dossier relatif à votre espace de travail. De cette façon, vous pouvez avoir autant de référentiels dans votre projet que nécessaire, le tout dans des emplacements distincts.

Autrement, si le projet que vous utilisez le permet, vous pouvez utiliser des sous-modules GIT, qui sont similaires aux chemins externes dans SVN. Dans le GIT Book , il y a une section sur ce sujet même. Si cela ne va pas à l'encontre de certaines règles, les sous-modules sont relativement simples à utiliser, ce qui vous permet de contrôler efficacement les emplacements, les versions/balises/branches qui seront importés ET sera disponible sur votre référentiel local, vous offrant ainsi une meilleure portabilité.

De toute évidence, le plug-in GIT prend en charge la vérification des sous-modules, afin que Jenkins puisse travailler avec eux de manière assez efficace.

39
Łukasz Rżanek

Je suis d'accord avec @ Łukasz Rżanek que nous pouvons utiliser plugin git

Mais, je me sers de l’option option: passer à une sous-direction qui est activée comme suit:
Dans Gestion du code source , cochez Git.
cliquez sur le bouton Ajouter, choisissez passez à un sous-répertoire

enter image description here

46
biolinh

Dans le nouveau pipeline Jenkins 2.0 (précédemment appelé le plug-in de flux de travail), cette opération est effectuée différemment pour:

  • Le référentiel principal
  • Autres dépôts supplémentaires

Ici, je fais spécifiquement référence à la version 2.9 du pipeline multibranche.

Dépôt principal

Ceci est le référentiel qui contient votre Jenkinsfile.

Dans l'écran Configure de votre projet de pipeline, entrez le nom de votre référentiel, etc.

N'utilisez pas Comportements supplémentaires> Extraire dans un sous-répertoire. Cela placera votre Jenkinsfile dans le sous-répertoire où Jenkins ne peut pas le trouver .

Dans Jenkinsfile, extrayez le référentiel principal du sous-répertoire en utilisant dir():

dir('subDir') {
    checkout scm
}

Dépôts supplémentaires

Si vous souhaitez consulter davantage de référentiels, utilisez le générateur Syntaxe de pipeline pour générer automatiquement un extrait de code Groovy.

Dans l'écran Configure de votre projet de pipeline:

  1. Sélectionnez Syntaxe du pipeline. Dans le menu déroulant Exemple d’étape, choisissez checkout: General SCM.
  2. Sélectionnez votre système SCM, tel que Git. Renseignez les informations habituelles sur votre référentiel ou votre dépôt.
  3. Notez que dans le pipeline multibranches, la variable d’environnement env.BRANCH_NAME contient le nom de la branche du référentiel principal.
  4. Dans le menu déroulant Comportements supplémentaires, sélectionnez Extraire vers un sous-répertoire
  5. Cliquez sur Generate Groovy. Jenkins affiche l'extrait de code Groovy correspondant à la vérification SCM que vous avez spécifiée.
  6. Copiez ce code dans votre script de pipeline ou Jenkinsfile.
33
John McGehee

Cela vaut la peine d’examiner le plugin Pipeline. Avec le plugin, vous pouvez extraire plusieurs projets VCS dans des chemins de répertoires relatifs. Créer au préalable un répertoire par extraction VCS. Emettez ensuite des commandes dans le nouvel espace de travail VCS. Dans mon cas, j'utilise git. Mais vous devriez avoir l'idée.

node{
    def exists = fileExists 'foo'
    if (!exists){
        new File('foo').mkdir()
    }
    dir ('foo') {
        git branch: "<ref spec>", changelog: false, poll: false, url: '<clone url>'
        ......
    }
    def exists = fileExists 'bar'
    if (!exists){
        new File('bar').mkdir()
    }
    dir ('bar') {
        git branch: "<ref spec>", changelog: false, poll: false, url: '<clone url>'
        ......
    }
    def exists = fileExists 'baz'
    if (!exists){
        new File('baz').mkdir()
    }
    dir ('baz') {
        git branch: "<ref spec>", changelog: false, poll: false, url: '<clone url>'
        ......
    }
}
17
Jeremy Whiting

De plus, si dans le même projet Jenkins, nous devons extraire plusieurs référentiels GitHub privés dans plusieurs répertoires distincts sous une racine de projet. Comment pouvons-nous le faire s'il vous plaît?

Le plugin Jenkin's Multiple SCMs a très bien résolu le problème des différents référentiels. Je viens de travailler sur une version de projet qui extrait quatre dépôts Git différents dans un dossier commun. (Je suis un peu réticent à utiliser les super-projets git comme suggéré précédemment de Łukasz Rżanek, car git est suffisamment complexe sans sous-modules.)

6
Alberto