Мы используем GitLab 11.5.0 и заметили странное поведение с коммитами подмодулей.
В нашем проекте есть субмодуль (назовем его subby), и он настроен примерно так вGitLab:
group
|--project
|--subby
Файл .gitmodules в project выглядит следующим образом:
[submodule "subby"]
path = subby
url = "../../group/subby.git"
Файл .gitlab-ci.yml в project содержит следующее (среди прочего):
variables:
GIT_SUBMODULE_STRATEGY: recursive
GIT_STRATEGY: clone
Разработчик внес изменения в код в subby, обновил ссылку на субмодуль в проекте и отправил запрос на слияние для каждого.Запрос на слияние для проекта был принят, но запрос для subby все еще находится на рассмотрении.
Когда Cit GitLab запустился, я ожидал, что он потерпит неудачу, поскольку subby не был объединен.Тем не менее, ему каким-то образом удалось найти новый неотгруженный коммит в subby и завершить сборку.Журнал CI показывает, что он создал ветвь с неотправленным коммитом субмодуля:
Updating/initializing submodules recursively...
Submodule 'subby' (https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@gitlab.example.com/group/subby.git) registered for path 'subby'
Cloning into '/builds/group/project/subby'...
From https://gitlab.example.com/group/subby
* branch c3499c2729730a7f807efb8676a92dcb6f8a3f8f -> FETCH_HEAD
Submodule path 'subby': checked out 'c3499c2729730a7f807efb8676a92dcb6f8a3f8f'
Даже странно, если я извлекаю недавно слитые файлы проекта и обновляю свой подмодуль с помощью git submodule update --init --recursive, он каким-то образом можетнайти неотправленный коммит в subby.
В более старой версии GitLab это просто привело бы к ошибке, из-за которой не удалось найти коммит субмодуля.Я предпочитаю старое поведение, потому что оно отражает тот факт, что вы не объединили зависимый коммит.
Мои вопросы:
- Как GitLab CI нашел необъединенный коммит?
- Как git / GitLab позволяет мне извлекать коммит субмодуля, который не был объединен?
- Как я могу вернуть GitLab к старому поведению, когда он просто не сможет найти коммит, если он не имеетбыли объединены?