Использование Git подмодулей с GitLab CI

Примечания:

• GitLab 8.12 ввел новую модель разрешений для CI-заданий и вам рекомендуется обновить вашу версию GitLab, если вы еще этого не сделали. Если вы не используете GitLab 8.12 или более позднюю версию, вам потребуется найти обходной путь для работы с подмодулями, чтобы получить доступ к исходному коду, например, gitlab.com/group/project с помощью SSH ключей.
• С GitLab 8.12 и далее ваши разрешения используются для оценки доступа для CI-заданий. Дополнительная информация о том, как работает эта система, доступна в разделе Модель разрешений для заданий.
• Протокол Git (HTTP(S)) должен быть включен в вашей версии GitLab.

Настройка файла .gitmodules

Если вы работаете с Git подмодулями, ваш проект, скорее всего, будет иметь файл с именем .gitmodules.

Рассмотрим следующий пример:

1. Ваш проект расположен по адресу https://gitlab.com/secret-group/my-project.
2. Чтобы получить доступ к вашему исходному коду, вы обычно используете SSH-адрес, например, git@gitlab.com:secret-group/my-project.git.
3. Ваш проект зависит от https://gitlab.com/group/project, который вы хотите включить как подмодуль.Если вы используете GitLab 8.12+ и ваш подмодуль находится на том же сервере GitLab, вы должны обновить свой файл .gitmodules, чтобы использовать относительные URL. Так как Git позволяет использовать относительные URL для конфигурации .gitmodules, это легко позволяет вам использовать HTTP(S) для клонирования всех ваших CI-заданий и SSH для всех ваших локальных клонов. Файл .gitmodules будет выглядеть следующим образом:```ini [submodule "project"] path = project url = ../../group/project.git

Вышеуказанная конфигурация будет инструктировать Git автоматически определять URL,
который должен быть использован при клонировании исходного кода. Независимо от того,
используете ли вы HTTP(S) или SSH, Git будет использовать тот же канал, и это позволит
всем вашим CI-заданиям использовать HTTP(S) (потому что GitLab CI использует только HTTP(S)
для клонирования ваших исходных кодов), и все ваши локальные клонирования продолжат использовать SSH.

Для всех других подмодулей, которые не находятся на том же сервере GitLab, используйте полный
URL протокола HTTP(S):

```ini
[submodule "project-x"]
  path = project-x
  url = https://gitserver.com/group/project-x.git

После правильной настройки файла .gitmodules вы можете перейти к настройке вашего .gitlab-ci.yml.

Использование Git подмодулей в ваших CI-заданиях

Чтобы сделать подмодули корректно работающими с вашими CI-заданиями, вам нужно выполнить несколько шагов:1. Сначала убедитесь, что вы используете относительные URL для подмодулей, расположенных на том же сервере GitLab.

1. Затем, если вы используете gitlab-ci-multi-runner версии 1.10 и выше, вы можете установить переменную GIT_SUBMODULE_STRATEGY на значение normal или recursive, чтобы указать запускающему выполнить получение ваших подмодулей перед выполнением задания:

   variables:
     GIT_SUBMODULE_STRATEGY: recursive

   Подробнее о переменной GIT_SUBMODULE_STRATEGY см. в справочнике .gitlab-ci.yml.1. Если вы используете более старую версию gitlab-ci-multi-runner, то используйте git submodule sync/update в before_script:

   before_script:
     - git submodule sync --recursive
     - git submodule update --init --recursive

   --recursive следует использовать либо в обоих, либо ни в одном из команд (sync/update) в зависимости от того, имеются ли у вас рекурсивные подмодули.

Основание для установки sync и update в before_script заключается в том, как работают Git подмодули. На свежем рабочем пространстве запускающего Git устанавливает URL подмодуля, включая токен, в .git/config (или .git/modules/<submodule>/config) на основе .gitmodules и текущего URL удаленного репозитория. В последующих заданиях на том же запускающем, .git/config кэшируется и уже содержит полный URL для подмодуля, соответствующий предыдущему заданию, и токен от предыдущего задания. Команда sync позволяет принудительно обновить полный URL.