как получить доступ к нескольким репозиториям в CI build?

у нас есть проект, состоящий из нескольких (непубличных) репозиториев.

чтобы построить весь проект, система сборки должна иметь файлы всех репозиториев (master филиалы).

есть ли способ настроить GitLab CI для предоставления необходимых репозиториев?

Я думаю, я мог бы сделать git fetch или аналогичный во время сборки CI, но как бороться с аутентификацией тогда?

11
gitlab gitlab-ci

3 ответов

вы можете добавить ключ развертывания ко всем проектам. Затем настройте закрытый ключ ключа развертывания на runner(s). Используйте обычные команды git в процессе сборки для клонирования репозиториев в runner. Это может потребовать немного конфигурации на ваших бегунах, но это должно работать.

вы можете создать одну пару ключей SSH и использовать ее на всех бегунах или создать одну пару ключей на бегуна. Чтобы создать пару ключей SSH, следуйте SSH ключ документация. Закрытый ключ должен быть помещен в "gitlab-runner" пользователя Так git команда может представить его во время клонирования. Открытый ключ должен быть добавлен в проект GitLab в качестве ключа развертывания. Добавьте ключ развертывания в настройках проекта - > 'Deploy Keys'.

4

Если вы используете gitlab версии 8.12 или более поздней, модель разрешений была переделанную. Наряду с этой новой моделью разрешений появляется переменная среды CI CI_JOB_TOKEN. Премиум-версия gitlab использует эту переменную среды для триггеров, но вы можете использовать ее для клонирования репозиториев.

dummy_stage:
  script:
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.instance/group/project.git
11

пара обходных путей (ненавижу это слово!) это обходной маневр для меня:

  1. используя git submodule см. https://docs.gitlab.com/ce/ci/git_submodules.html

  2. повторное использование CI_REPOSITORY_URL$ определенный Gitlab и доступный даже внутри контейнеров Docker ребенка. Этот env var уже содержит имя пользователя и пароль, которые можно использовать для другого РЕПО на том же сервере. См. фрагмент из .gitlab-ci.в формате YML:

- BASE_URL=`echo $CI_REPOSITORY_URL | sed "s;\/*$CI_PROJECT_PATH.*;;"`
- REPO_URL="$BASE_URL/thirdparty/gtest.git"
- REPO_DIR=thirdparty/gtest
- rm -fr $REPO_DIR
- git clone $REPO_URL $REPO_DIR
  1. даже сохранение этого URL с именем пользователя\паролем в ~/.git-учетные данные файл и настройка git для его использования через учетные данные.помощник. Все дальнейшие команды "git clone" будут использовать его.
- echo Storing git credentials to be used by "git clone" commands without username and password ...
- GIT_CREDENTIALS_FILE=~/.git-credentials
- BASE_URL=`echo $CI_REPOSITORY_URL | sed "s;\/*$CI_PROJECT_PATH.*;;"`
- echo $BASE_URL > $GIT_CREDENTIALS_FILE
- git config --global credential.helper store --file=$GIT_CREDENTIALS_FILE

однако !

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

Да, в классических инструментах CI, таких как Jenkins или TeamCity, вы можете создать задание, которое извлекает несколько репозиториев Git в разных подкаталогах.

но мне нравится GitLab CI способ конвейера как Код, где .gitlab-ci.yml контролирует сборку этого самого РЕПО, и вам даже не нужно думать об этом шаге предварительной сборки получения источников. Тогда такая сборка опубликовала бы бинарные артефакты и последующие проекты\repos могут использовать их вместо из источник зависимостей. Это также быстрее.

разделение проблем.

у меня нет официального способа в моем .gitlab-ci.yml для использования артефактов другого проекта. Но есть и другие способы, такие как hooks, GitLab API, хотя такие индивидуальные решения требуют обслуживания.

есть лучший способ-опубликовать артефакты\fetch в\из внешнего широко принятого диспетчера пакетов. В зависимости от вашего языка это может быть Maven, NuGet, npm, jFrog Artifactory, Nexus, etc. Еще одним преимуществом этого метода является то, что разработчики могут выполнять тот же процесс в своих локальных сборках, что нелегко сделать, если определены зависимости .gitlab-ci.в формате YML

это большая проблема для собственного кода (Cxx) в основном из-за совместимости двоичного интерфейса, но такие вещи, как Conan.io и т. д. медленно догоняют.

6