Получение GitLab CI для клонирования частных репозиториев

У меня есть GitLab и GitLab CI, настроенные для размещения и тестирования некоторых моих личных репозиториев. Для моих модулей-композиторов в этой системе у меня есть Satis для решения моих личных пакетов.

Очевидно, что этим частным пакетам требуется ключ ssh для клонирования, и у меня это работает в терминале - я могу запустить установку композитора и получить эти пакеты, если у меня есть ключ, добавленный с помощью ssh-add в оболочке.

Однако при выполнении моих тестов в GitLab CI, если у проекта есть какие-либо из этих зависимостей, тесты не будут завершены, так как мой экземпляр GitLab нуждается в аутентификации, чтобы получить отпечатки (очевидно), и тест не работает, говоря Host key verification failed.

Мой вопрос в том, как мне настроить это так, чтобы, когда бегун запускает тест, он может аутентифицироваться в gitlab без пароля? Я попытался установить ssh-ключ без пароля в моей папке ~/.ssh, однако сама по себе конструкция не добавит ключ, "eval ssh-agent -s", за которым следует ssh-add, кажется, не работает, заявив, что агент не запущен...

Ответ 1

Я отправляю это как ответ, так как другие не были полностью ясны и/или детализированы IMHO

Начиная с GitLab 8.12+, если репозиторий подмодуля находится на том же сервере, что и тот, который его запрашивает, вы можете теперь:

Настройте репо с подмодулями git как обычно (git submodule add [email protected]:folder/mysubmodule.git)
Измените файл .gitmodules следующим образом
```
[submodule "mysubmodule"]
  path = mysubmodule
  url = ../../group/mysubmodule.git
```
где `../../group/mysubmodule.git '- относительный путь из вашего репозитория к подмодульному.
Добавьте следующие строки в gitlab-ci.yml
```
variables:
  GIT_SUBMODULE_STRATEGY: recursive
```
чтобы проинструктировать бегун для получения всех подмодулей до сборки.

Предостережение: если ваш бегун, похоже, игнорирует директиву GIT_SUBMODULE_STRATEGY, вам следует, вероятно, рассмотреть обновление.

(источник: https://docs.gitlab.com/ce/ci/git_submodules.html)

Ответ 2

Вот полный способ:

Общая конструкция

создание пары ключей SSH
добавление частного в качестве переменной безопасной среды вашего проекта.
сделать доступным доступное для ваших тестовых скриптов на GitLab-CI
добавление открытого в качестве ключа развертывания в каждой из ваших личных зависимостей

Создание пары открытых и закрытых SSH-ключей

Создайте пару открытых и закрытых SSH-ключей без кодовой фразы:

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

Добавление личного ключа SSH в ваш проект

Вам нужно добавить ключ в качестве защищенной переменной среды для вашего проекта, как следующее:

просмотреть https://<gitlab_host>/<group>/<project_name>/variables
нажмите "Добавить переменную"
заполните текстовое поле Key с помощью SSH_PRIVATE_KEY
заполните текстовое поле Value с помощью собственного SSH-ключа
нажмите "Сохранить изменения"

Предоставление личного ключа SSH для тестовых скриптов

Чтобы ваш секретный ключ был доступен для ваших тестовых скриптов, вам нужно добавить в ваш .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 ssh config
  - mkdir -p ~/.ssh
  - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config

Фрагмент кода поступает из документации GitLab

Добавление открытого SSH-ключа в качестве ключа развертывания ко всем вашим личным зависимостям

Вам необходимо зарегистрировать открытый SSH-ключ в качестве ключа развертывания для всех ваших личных как:

просматривать https://<gitlab_host>/<group>/<dependency_name>/deploy_keys
нажмите "Новый ключ развертывания"
заполните текстовое поле Title именем вашего проекта
заполнить текстовое поле Key самим открытым SSH-ключом
нажмите "Создать ключ развертывания"

Ответ 3

Исправлено это, добавив ключ к известным хостам с помощью ssh-keyscan -H 'localgitlab.co.uk' >> ~gitlab_ci_runner/.ssh/known_hosts

Ответ 4

Я использовал токены развертывания для решения этой проблемы, так как настройка ключей SSH для тестового бегуна кажется немного затянутой.

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

Токены развертывания относятся к каждому проекту и доступны только для чтения.

Ответ 5

Если вы не хотите возиться с ssh-ключами или подмодулями, вы можете переопределить хранилище в конфигурации git для аутентификации с помощью токена задания (в 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

Ответ 6

Похоже, что существует разумное решение.

Короче говоря, с GitLab 8.12 все, что вам нужно сделать, это использовать относительные пути в .submodules, а git submodule update --init будет просто работать

Ответ 7

У меня был сценарий, в котором я должен был использовать свой ssh-ключ в трех разных сценариях, поэтому я помещал материал ssh в одну оболочку script и сначала вызывал его перед другими 3 сценариями. Это закончилось тем, что не работает, я думаю, из-за ssh-agent, не сохраняющегося между сценариями оболочки, или что-то в этом роде. В итоге я просто вывел закрытый ключ в файл ~/.ssh/id_rsa, который наверняка сохранится и для других скриптов.

.gitlab-ci.yml

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

Ки/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

Он работает как шарм!

Ответ 8

В настоящее время принятый ответ встраивает специфичные для Gitlab требования в мой файл .gitmodules. Это вынуждает конкретную структуру каталогов для локальной разработки и усложняет переход на другую платформу управления версиями.

Вместо этого я последовал совету в ответе Juddling. Здесь более полный ответ.

Мои файлы .gitmodules имеют следующее содержимое:

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

В моем gitlab-ci.yml меня есть следующее:

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

Трейлинг / и : являются критическими в строке git config, так как мы сопоставляем аутентификацию SSH с HTTPS. Это сбило меня с толку из-за ошибок "Недопустимый номер порта".

Мне нравится это решение, потому что оно встраивает специфичные для Gitlab требования в специфичный для Gitlab файл, который игнорируется всем остальным.