wake-up-neo.net

GitLab CI zum Klonen privater Repositories verwenden

Ich habe GitLab & GitLab CI als Host eingerichtet und teste einige meiner privaten Repos. Für meine Composer-Module unter diesem System habe ich Satis eingerichtet, um meine privaten Pakete aufzulösen.

Offensichtlich benötigen diese privaten Pakete einen ssh-Schlüssel, um sie zu klonen, und ich habe dies im Terminal. Ich kann Composer installieren und diese Pakete abrufen, solange ich den Schlüssel mit ssh-add in der Shell hinzugefügt habe.

Bei der Ausführung meiner Tests in GitLab CI werden die Tests jedoch nicht abgeschlossen, wenn ein Projekt über eine dieser Abhängigkeiten verfügt, da meine GitLab-Instanz eine Authentifizierung zum Abrufen der Deps benötigt (offensichtlich), und der Test schlägt fehl, Host key verification failed zu sagen.

Meine Frage ist, wie kann ich das so einrichten, dass der Läufer, wenn er den Test ausführt, sich ohne Passwort bei gitlab authentifizieren kann? Ich habe versucht, einen ssh-Schlüssel ohne Kennwort in meinen ~/.ssh-Ordner des Läufers zu legen, der Build wird jedoch nicht einmal den Schlüssel hinzufügen. "Eval ssh-agent -s" gefolgt von ssh-add scheint fehlzuschlagen, der Agent läuft nicht ...

30
danbroooks

Ich poste dies als Antwort, da andere IMHO nicht vollständig klar und/oder detailliert waren

Ausgehend von GitLab 8.12+ können Sie, sofern sich das Repository des Submoduls auf demselben Server befindet wie der, der es anfordert, jetzt wie folgt vorgehen:

  1. Repo mit git Submodules wie gewohnt einrichten (git submodule add [email protected]:folder/mysubmodule.git)

  2. Ändern Sie Ihre .gitmodules-Datei wie folgt

    [submodule "mysubmodule"]
      path = mysubmodule
      url = ../../group/mysubmodule.git
    

    dabei ist "../../group/mysubmodule.git" ein relativer Pfad von Ihrem Repository zum Pfad des Submoduls.

  3. Fügen Sie die folgenden Zeilen zu gitlab-ci.yml hinzu.

    variables:
      GIT_SUBMODULE_STRATEGY: recursive
    

    den Runner anzuweisen, alle Submodule vor des Builds abzurufen.

Vorbehalt: Wenn Ihr Läufer die GIT_SUBMODULE_STRATEGY-Direktive zu ignorieren scheint, sollten Sie wahrscheinlich erwägen, zu aktualisieren .

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

15
Marco A.

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".
37
toch

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
5
a544jh

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

4
danbroooks

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.

3
Juddling

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.

2
Duncan Jones

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!

0
user3246077

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

0
Eri Rubin