GitLab CI zum Klonen privater Repositories verwenden

Hier eine vollständige Anleitung:

Allgemeines Design

• erzeugen eines Paares von SSH-Schlüsseln
• hinzufügen der privaten als sichere Umgebungsvariable Ihres Projekts
• machen Sie das private für Ihre Testskripte auf GitLab-CI verfügbar
• hinzufügen des öffentlichen Schlüssels als Bereitstellungsschlüssel für jede Ihrer privaten Abhängigkeiten

Generieren eines Paares öffentlicher und privater SSH-Schlüssel

Generieren Sie ein Paar öffentlicher und privater SSH-Schlüssel ohne Passphrase:

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

Hinzufügen des privaten SSH-Schlüssels zu Ihrem Projekt

Sie müssen den Schlüssel als sichere Umgebungsvariable als Zu Ihrem Projekt hinzufügen:

• https://<gitlab_Host>/<group>/<project_name>/variables durchsuchen
• klicken Sie auf "Variable hinzufügen".
• fülle das Textfeld Key mit SSH_PRIVATE_KEY
• füllen Sie das Textfeld Value mit dem privaten SSH-Schlüssel
• klicken Sie auf "Änderungen speichern".

Offenlegen des privaten SSH-Schlüssels für Ihre Testskripte

Um Ihren privaten Schlüssel für Ihre Testskripte verfügbar zu machen, müssen Sie Ihrer .gitlab-ci.yml-Datei Folgendes hinzufügen:

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

Code Snippet stammt aus der GitLab-Dokumentation

Hinzufügen des öffentlichen SSH-Schlüssels als Implementierungsschlüssel zu allen privaten Abhängigkeiten

Sie müssen den öffentlichen SSH-Schlüssel als Implementierungsschlüssel für alle Ihre privaten Abhängigkeiten registrieren, wie folgt:

• https://<gitlab_Host>/<group>/<dependency_name>/deploy_keys durchsuchen
• klicken Sie auf "Neuer Bereitstellungsschlüssel".
• füllen Sie das Textfeld Title mit dem Namen Ihres Projekts
• füllen Sie das Textfeld Key mit dem öffentlichen SSH-Schlüssel
• klicken Sie auf "Bereitstellungsschlüssel erstellen".

Wenn Sie nicht mit ssh-Schlüsseln oder Submodulen herumspielen möchten, können Sie das Repo in gits Konfiguration überschreiben, um sich stattdessen mit dem Job-Token zu authentifizieren (in 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

Behebung des Problems durch Hinzufügen des Schlüssels zu bekannten Hosts mit ssh-keyscan -H 'localgitlab.co.uk' >> ~gitlab_ci_runner/.ssh/known_hosts

Ich habe deploy tokens verwendet, um dieses Problem zu lösen, da das Einrichten von SSH-Schlüsseln für einen Testläufer etwas langwierig erscheint.

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

Die Bereitstellungstoken sind pro Projekt und sind schreibgeschützt.

Die aktuell akzeptierte Antwort bindet Gitlab-spezifische Anforderungen in meine .gitmodules-Datei ein. Dies erzwingt ein spezifisches Verzeichnislayout für die lokale Entwicklung und würde den Umstieg auf eine andere Versionskontrollplattform erschweren.

Stattdessen folgte ich dem Rat in Juddlings Antwort . Hier ist eine vollständigere Antwort.

Meine .gitmodules-Dateien haben folgenden Inhalt:

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

In meinem gitlab-ci.yml habe ich folgendes:

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

Der nachfolgende / und : sind in der git config-Zeile kritisch, da wir von der SSH-Authentifizierung auf HTTPS abbilden. Dies hat mich mit "Illegal port number" -Fehlern für eine Weile ausgelöst.

Diese Lösung gefällt mir, weil sie die Gitlab-spezifischen Anforderungen in eine Gitlab-spezifische Datei einbettet, die von allem anderen ignoriert wird.

Ich hatte ein Szenario, in dem ich meinen SSH-Schlüssel in 3 verschiedenen Skripts verwenden musste. Deshalb habe ich die SSH-Schlüsselelemente in ein einziges Shell-Skript eingefügt und es zuerst aufgerufen, bevor die anderen 3 Skripts aufgerufen wurden. Dies hat letztendlich nicht funktioniert, denke ich, weil ssh-agent nicht zwischen Shell-Skripten bestehen bleibt oder etwas zu diesem Zweck. Am Ende gab ich eigentlich nur den privaten Schlüssel in die ~/.ssh/id_rsa-Datei aus, die auf jeden Fall für andere Skripte bestehen bleibt.

.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

Es wirkt wie ein Zauber!

Scheint da endlich eine vernünftige Lösung .

Kurz gesagt, ab GitLab 8.12 müssen Sie nur relative Pfade im .submodules verwenden, und der git submodule update --init funktioniert einfach