Jenkins: Récupération de sous-modules avec Git
Actuellement, je suis bloqué sur un problème qui tente de récupérer les sous-modules d'un référentiel à partir de Jenkins. Ma configuration est correcte et je peux extraire des référentiels sans aucun sous-module.
Je peux également extraire les composants principaux d'un référentiel avec des sous-modules (avec l'authentification dans le nom du référentiel comme avec SSH). Le problème ne se pose que lorsque je dois extraire les composants du sous-module. J'utilise la dernière version de Jenkins et j'ai ajouté une partie en bas qui concerne les "Comportements avancés de sous-modules". J'ai sélectionné "Mettre à jour récursivement les sous-modules" ici et ai exécuté la construction plusieurs fois en vain.
Lorsque j'essaie d'ajouter une étape de construction supplémentaire en bas avec des commandes Shell, la mise à jour des référentiels ne fonctionne pas non plus. Lorsque j'essaie ces commandes en dehors de Jenkins dans mon terminal, cela fonctionne très bien. Le problème que je rencontre toujours à Jenkins est le suivant:
FATAL: Command "git submodule update" returned status code 1:
stdout:
stderr: Cloning into 'thisismysubmodule'...
fatal: Authentication failed for 'https://git.thisismyrepo.com/scm/ap/thisismysubmodule.git/'
J'ai trouvé ce problème: https://issues.jenkins-ci.org/browse/JENKINS-20941 mais je ne peux pas utiliser la solution suggérée ci-dessous pour des raisons de sécurité. Est-ce que quelqu'un ici a une expérience avec ce problème ou une solution possible?
Voici une solution de contournement utilisant Transfert d’agent SSH . Cela a bien fonctionné pour moi.
- Tout d’abord, éditez
<jenkins_home>/.ssh/configet définissez ForwardAgent yes - Ensuite, installez SSH Agent plugin pour Jenkins.
- Ensuite, dans la configuration du projet, réinitialisez les informations d'identification Git.
- Enfin, dans la configuration du projet, définissez les informations d'identification de l'agent SSH.
Les versions bêta des modules git-client et git-plug-in ont été publiées pour résoudre ce problème. Pour citer le problème JIRA.
Le plugin client git 2.0.0-beta1 a été publié dans le centre de mise à jour expérimentale. Il inclut l’authentification de sous-module git, JGit 4.3, et nécessite JDK 7. Il nécessite au moins Jenkins 1.625 (la première version pour mandater JDK 7).
En utilisant ce qui précède, il existe une option dans la section Comportements supplémentaires appelée:
Utiliser les informations d'identification du référentiel parent distant par défaut
Cela a résolu mon problème lors de l'utilisation de Jenkins 2.11 et des versions bêta du plug-in exécutant un serveur Windows et un esclave. En outre, vous devez utiliser la même méthode d'authentification. Si vous utilisez http, vous devez également l'utiliser pour les sous-modules. Si vous utilisez SSH, vous devez l'utiliser pour les sous-modules. Essayer de mélanger les méthodes ne fonctionnera pas. correctement.
-- METTRE À JOUR --
Les versions bêta ne sont plus nécessaires, veuillez consulter les pages suivantes:
Git Client Plugin
Git Plugin
En fait, je viens juste de le déplacer vers une commande Shell et dans la commande Shell, je lui ai dit quel assistant d'identification utiliser, étant donné que je suis sous windows, il a été créé:
git config --global credential.helper wincred
git submodule init
git submodule sync
git submodule update --init --recursive
Une solution consisterait à déclarer dans le fichier de configuration global git une aide d’identification Netrc, qui fournirait les informations d’identification nécessaires pour toute requête http provenant de git.
git config --global credential.helper "netrc -f C:/path/to/_netrc.gpg -v"
(assurez-vous d'utiliser le même compte que celui utilisé pour exécuter Jenkins)
J'utilise un fichier netrc chiffré , mais vous pouvez commencer un test avec un fichier non chiffré.
Considérant que j'ai essayé à peu près toutes les options disponibles pour que cela fonctionne (SSH, .netrc, informations d'identification codées en dur, ...), la seule option était celle qui était mentionnée au bas du numéro de JENKINS-20941 par 'andreg':
Oui, cette question est une vraie douleur pour nous aussi. La seule façon dont nous pourrions obtenir Pour notre configuration Stash/Jenkins, il fallait créer un utilisateur en lecture seule et pour coder en dur les informations d'identification de cet utilisateur dans la référence au sous-module. Bien que cela soit une mauvaise pratique, tous les utilisateurs travaillant sur le dépôt git avez déjà au moins un accès en lecture seule, nous n'avons donc pas eu l'impression que c'était trop beaucoup de problème de sécurité. par exemple. dans le fichier .gitmodules du référentiel parent:
[sous-module "bibliothèque partagée"] chemin = bibliothèque partagée url = https: // nom d'utilisateur: [email protected]/scm/project/shared-library.git
puis le travail Jenkins a "Mettre à jour récursivement les sous-modules" sélectionné.
J'ai réussi à le faire fonctionner en ajoutant simplement un fichier .netrc avec les informations d'identification sur Linux. Ce n’est pas la solution la plus sûre, mais si vous devez la faire fonctionner rapidement, vous pourrez vous y mettre.
Cette solution a fonctionné pour moi:
- Assurez-vous que les informations d'identification ssh sont les mêmes pour le référent parent et le référentiel de sous-module.
- Configurez les informations d'identification du référent parent dans Jenkins. (Gestion du code source (choisissez "Git")> Référentiels)
Configurez votre fichier .gitmodule de sorte qu'il utilise les informations d'identification ssh du référent parent:
[submodule "foo/repository"] path = foo/repository url = ssh://[email protected]/repositoryIl y a une petite mise en garde à cette solution. Chaque fois que quelqu'un clone le référant parent, il devra synchroniser l'URL avec celle à laquelle il a accès. La première fois qu'un utilisateur initialise le sous-module, il doit d'abord éditer le fichier .gitmodules et changer l'URL:
[submodule "foo/repository"] path = foo/repository url = ssh://[email protected]/repositoryEnsuite, dans le terminal:
git submodule sync git submodule init repository git submodule update --remote repositoryEt puis changez l'URL en jenkins build url. À moins que vous ne synchronisiez à nouveau, le sous-module utilisera l'URL associée à l'utilisateur.
En septembre 2016, Jenkins prévoit de publier une nouvelle fonctionnalité qui permettra aux sous-modules de partager les informations d'identification du référentiel parent. Ensuite, une URL HTTP peut être utilisée dans .gitmodule au lieu de ssh.