У нас есть проект, состоящий из нескольких (непубличных) репозиториев.
Чтобы построить весь проект, система сборки должна иметь файлы всех репозиториев (ветки master).
Есть ли способ настроить GitLab CI для предоставления репозиториев, которые мне нужны?
Думаю, я мог бы сделать git fetch или подобное во время сборки CI, но как это сделать с аутентификацией?
Вы можете добавить ключ развертывания ко всем проектам. Затем настройте закрытый ключ развертывания на бегун (ы). Используйте обычные команды git в процессе сборки, чтобы клонировать репозитории на бегуне. Это может потребовать немного конфигурации на ваших бегунах, но оно должно работать.
Вы можете создать одну пару ключей SSH и использовать ее на всех бегунах или создать одну пару ключей для каждого бегуна. Чтобы создать пару ключей SSH, следуйте странице SSH. Закрытый ключ должен быть помещен в каталог пользователя .ssh пользователя gitlab-runner, поэтому команда git может представить его во время клонирования. Открытый ключ следует добавить в проект GitLab в качестве ключа развертывания. Добавьте ключ развертывания в параметры проекта → "Развернуть ключи".
Если вы работаете с gitlab версии 8.12 или новее, модель прав доступа была переработана. Наряду с этой новой моделью разрешений CI_JOB_TOKEN переменная среды CI CI_JOB_TOKEN. Премиум-версия GitLab использует эту переменную среды для триггеров, но вы можете использовать ее для клонирования репозиториев.
dummy_stage:
script:
- git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.instance/group/project.git
Несколько обходных путей (я ненавижу это слово!), Которые обходят меня стороной:
Используя git submodule, смотрите https://docs.gitlab.com/ce/ci/git_submodules.html.
Повторное использование $ 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
- 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, способ Pipeline As Code, где .gitlab-ci.yml контролирует сборку этого самого репозитория, и вам даже не нужно думать о целой стадии предварительной сборки получения исходных текстов. Тогда такая сборка будет публиковать бинарные артефакты, и последующие проекты\репозитории могут использовать их вместо источников зависимостей. Это также быстрее.
Разделение проблем.
В моем .gitlab-ci.yml есть официальный способ использовать артефакты другого проекта. Но есть и другие способы, такие как хуки, Gitlab API, хотя такие индивидуальные решения требуют обслуживания.
Есть лучший способ - публиковать\извлекать артефакты в\из внешнего широко распространенного менеджера пакетов. В зависимости от вашего языка это могут быть Maven, NuGet, npm, jFrog Artifactory, Nexus и т.д. Еще одним преимуществом этого метода является то, что разработчики могут следовать одному и тому же процессу в своих локальных сборках, что нелегко сделать, если в .gitlab определены зависимости. -ci.yml
Это большая проблема для нативного кода (Cxx), в основном из-за совместимости двоичного интерфейса, но такие вещи, как Conan.io и т.д. Постепенно догоняют.