Подобная проблема обсуждается в gitlab-org/gitlab-foss выпуске 41560
Пример использования:
Я хочу всегда pu sh тот же Docker "image: tag", например: "myapp: dev-CI". Идея состоит в том, что «myapp: dev-CI» всегда должен быть последним Docker образом приложения, которое соответствует HEAD ветви разработки.
Однако, если 2 коммита выдвинуты, то 2 конвейера запускаются и выполняются в paralell. Затем последний запущенный конвейер часто заканчивается раньше, чем самый старый.
Как следствие, помещенное Docker изображение не является последним.
Предложение :
В качестве обходного пути для * nix вы можете получить запущенные конвейеры из API и подождать, пока они не завершат, или отменить их с тем же API.
В приведенном ниже примере скрипт проверяет наличие конвейеров с более низким идентификатором для того же ветвь и спит.
jq пакет необходим для работы этого кода.
или :
- Создать нового бегуна экземпляр
- Сконфигурируйте его для запуска заданий, помеченных как развертывание с помощью
concurrency 1 - Добавьте тег развертывания к заданию на компакт-диске.
Теперь невозможно выполнить два задания развертывания для одновременного запуска.
Чтобы защититься от ситуации, когда более старый конвейер может запускаться после нового, добавьте проверку в задании развертывания, чтобы выйти, если текущий идентификатор конвейера меньше текущего развертывания.
Сли Модификация ght :
Для меня одно небольшое изменение: я оставил глобальные настройки concurrency одинаковыми (8 участников на моей машине, поэтому одновременность: 8).
Но я пометил одного из бегунов deploy и добавил limit: 1 в его конфигурацию.
Затем я обновил свой .gitlab-ci.yml, чтобы использовать тег deploy в моей работе deploy.
Отлично работает: мой * Задание 1057 * может выполняться одновременно на 7 участниках, но deploy является «однопоточным», а любые другие deploy задания go переходят в состояние ожидания до тех пор, пока этот участник не освободится.