Demander à GitLab CI de cloner des référentiels privés

J'ai configuré GitLab & GitLab CI pour héberger et tester certaines de mes pensions privées. Pour mes modules de composition sous ce système, Satis a été configuré pour résoudre mes paquets privés.

Il est évident que ces paquets privés nécessitent une clé ssh pour les cloner, et cela fonctionne dans le terminal. Je peux exécuter l'installation de composer et obtenir ces paquets, tant que la clé est ajoutée avec ssh-add dans le shell.

Cependant, lors de l'exécution de mes tests dans GitLab CI, si un projet comporte l'une de ces dépendances, les tests ne seront pas terminés car mon instance GitLab a besoin d'une authentification pour obtenir les dépôts (évidemment), et le test échoue en indiquant Host key verification failed.

Ma question est la suivante: comment puis-je configurer cela pour que, lorsque le coureur exécute le test, il puisse s'authentifier auprès de gitlab sans mot de passe? J'ai essayé de mettre une clé ssh sans mot de passe dans mon dossier ~/.ssh des coureurs. Cependant, la construction n'ajoutera même pas la clé, "eval ssh-agent -s" suivie par ssh-add semble échouer en disant que l'agent n'est pas en cours d'exécution ...

sshcontinuous-integrationgitlabgitlab-cigitlab-ci-runner

5 sept. 2014danbroooks

Je poste ceci comme une réponse puisque d'autres n'étaient pas complètement clairs et/ou détaillés IMHO

À partir de GitLab 8.12+, en supposant que le référentiel de sous-module se trouve sur le même serveur que celui qui le demande, vous pouvez maintenant:

Configurez le dépôt avec les sous-modules git comme d'habitude (git submodule add git@somewhere:folder/mysubmodule.git)
Modifiez votre fichier .gitmodules comme suit
```
[submodule "mysubmodule"]
  path = mysubmodule
  url = ../../group/mysubmodule.git
```
où `../../group/mysubmodule.git 'est un chemin relatif de votre référentiel à celui du sous-module.
Ajoutez les lignes suivantes à gitlab-ci.yml
```
variables:
  GIT_SUBMODULE_STRATEGY: recursive
```
demander au coureur de récupérer tous les sous-modules avant la construction.

Mise en garde: si votre coureur semble ignorer la directive GIT_SUBMODULE_STRATEGY, vous devriez probablement envisager de le mettre à jour .

(source: https://docs.gitlab.com/ce/ci/git_submodules.html )

14 févr. 2017Marco A.

Voici un howto complet:

Conception générale

générer une paire de clés SSH
ajout de la variable privée en tant que variable d'environnement sécurisé de votre projet
rendre le privé disponible pour vos scripts de test sur GitLab-CI
ajout de la clé publique en tant que clé de déploiement sur chacune de vos dépendances privées

Génération d'une paire de clés SSH publiques et privées

Générez une paire de clés SSH publiques et privées sans phrase secrète:

ssh-keygen -b 4096 -C "<name of your project>" -N "" -f /tmp/name_of_your_project.key

Ajout de la clé privée SSH à votre projet

Vous devez ajouter la clé en tant que variable d’environnement sécurisé à votre projet sous la forme Suivante:

parcourir https://<gitlab_Host>/<group>/<project_name>/variables
cliquer sur "Ajouter une variable"
remplissez le champ Key avec SSH_PRIVATE_KEY
remplissez le champ de texte Value avec la clé privée SSH elle-même
cliquez sur "Enregistrer les modifications"

Exposer la clé privée SSH à vos scripts de test

Afin de rendre votre clé privée disponible pour vos scripts de test, vous devez ajouter ce qui suit à votre fichier .gitlab-ci.yml:

before_script:
  # install ssh-agent
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  # run ssh-agent
  - eval $(ssh-agent -s)
  # add ssh key stored in SSH_PRIVATE_KEY variable to the agent store
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  # disable Host key checking (NOTE: makes you susceptible to man-in-the-middle attacks)
  # WARNING: use only in docker container, if you use it with Shell you will overwrite your user's ssh config
  - mkdir -p ~/.ssh
  - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config

L'extrait de code provient de la documentation de GitLab

Ajout de la clé publique SSH en tant que clé de déploiement à toutes vos dépendances privées

Vous devez enregistrer la clé publique SSH en tant que clé de déploiement pour toutes vos dépendances privées Comme suit:

parcourir https://<gitlab_Host>/<group>/<dependency_name>/deploy_keys
cliquez sur "Nouvelle clé de déploiement"
remplissez le champ de texte Title avec le nom de votre projet
remplissez le champ de texte Key avec la clé publique SSH elle-même
cliquez sur "Créer la clé de déploiement"

25 juil. 2016toch

Si vous ne voulez pas jouer avec les clés ssh ou les sous-modules, vous pouvez remplacer le référentiel dans la configuration de git pour s'authentifier avec le jeton de travail (dans gitlab-ci.yml):

before_script:
  - git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/group/repo.git".insteadOf [email protected]:group/repo.git

29 mars 2018a544jh

Corrigé ceci en ajoutant la clé aux hôtes connus avec ssh-keyscan -H 'localgitlab.co.uk' >> ~gitlab_ci_runner/.ssh/known_hosts

6 sept. 2014danbroooks

J'ai utilisé deploy tokens pour résoudre ce problème, car la configuration des clés SSH pour un coureur test semble un peu longue.

git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git

Les jetons de déploiement sont par projet et en lecture seule.

8 juil. 2018Juddling

La réponse actuellement acceptée intègre les exigences spécifiques de Gitlab dans mon fichier .gitmodules. Cela impose une disposition de répertoire spécifique pour le développement local et compliquerait le passage à une autre plate-forme de contrôle de version.

Au lieu de cela, j'ai suivi le conseil de réponse de Juddling . Voici une réponse plus complète.

Mes fichiers .gitmodules ont le contenu suivant:

[submodule "myproject"]
    url = [email protected]:mygroup/myproject.git

Dans mon gitlab-ci.yml, j'ai les éléments suivants:

build:
  stage: build
  before_script:
    - git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@git.myhost.com/".insteadOf "[email protected]:"
    - git submodule sync && git submodule update --init

Les / et : de fin sont critiques dans la ligne git config, car nous mappons de l'authentification SSH à HTTPS. Cela m'a fait trébucher pendant un moment avec des erreurs "Illegal port number".

J'aime cette solution car elle intègre les exigences spécifiques à Gitlab dans un fichier spécifique à Gitlab, qui est ignoré par tout le reste.

13 déc. 2018Duncan Jones

J'avais un scénario dans lequel je devais utiliser ma clé ssh dans 3 scripts différents. J'ai donc placé le contenu de la clé ssh dans un seul script Shell et je l'ai appelé avant les 3 autres scripts. Cela a fini par ne pas fonctionner, je pense en raison du ssh-agent qui ne persiste pas entre les scripts Shell, ou quelque chose du genre. En fin de compte, j'ai simplement sorti la clé privée dans le fichier ~/.ssh/id_rsa, qui persistera certainement dans d'autres scripts.

.gitlab-ci.yml

script:
    - ci/init_ssh.sh
    - git Push # or whatever you need ssh for

ci/init_ssh.sh

# only run in docker:
[[ ! -e /.dockerenv ]] && exit 0

mkdir -p ~/.ssh
echo "$GITLAB_RUNNER_SSH_KEY" > ~/.ssh/id_rsa
chmod 400 ~/.ssh/id_rsa
echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > /.ssh/config

Il fonctionne comme un charme!

15 juin 2017user3246077

Il semble y avoir enfin une solution raisonnable .

En bref, à partir de GitLab 8.12, tout ce que vous avez à faire est d’utiliser des chemins relatifs dans le .submodules, et le git submodule update --init fonctionnera simplement.

23 nov. 2016Eri Rubin