GitLab-CI : ограничение параллельных каналов для одной и той же ветви

# #gitlab

Вопрос:

Мы только что перешли с Jenkins на GitLab-CI и имеем канал с несколькими этапами, такими как

 build -> test 1 -> test 2 -> test 3 -> deploy
 

Артефакты создаются на этапе сборки и используются на последующих этапах, а общее время запуска канала составляет ~2 часа.

Наша настройка устроена таким образом, что если параллельно запускается другой канал для той же ветви, он перезаписывает существующие артефакты, созданные предыдущим каналом, и предыдущий канал выходит из строя.

Допустим, у нас уже работает труба № 1 для ответвления master , а другая труба № 2 запускается master через 30 минут, затем артефакт трубы № 1 удаляется, и она выходит из строя.

В случае Дженкинса мы смогли ограничить параллельные трубы, используя приведенную ниже конфигурацию :

 options {
    disableConcurrentBuilds()
}

 

Но мы не можем найти аналогичную конфигурацию для GitLab-CI.

Мы уже пробовали решение, предложенное «@Simon Schrottner » в разделе комментариев, но оно работает только на уровне заданий, но не на уровне конвейера, мы добавили группу ресурсов для всех заданий в трубопроводе, как показано ниже :

 build:
  script: echo "build"
  resource_group: "group1"

test:
  script: echo "test"
  resource_group: "group1"

deploy:
  script: echo "deploy"
  resource_group: "group1"
 

Обратите внимание, что мы выполняем все задания в трубе последовательно.

Но при такой настройке вместо того, чтобы ждать, пока первый канал завершит все задания, задания из обоих каналов выполнялись случайным образом, как показано ниже

Ожидается : Труба № 2 подождите, пока все этапы трубы № 1 не будут завершены

 Pipe #1 : build(started) -> test -> deploy
Pipe #2 : build(waiting) -> test -> deploy

Pipe #1 : build(finished) -> test(started) -> deploy
Pipe #2 : build(waiting) -> test -> deploy

Pipe #1 : build(finished) -> test(finished) -> deploy(started)
Pipe #2 : build(waiting) -> test -> deploy

Pipe #1 : build(finished) -> test(finished) -> deploy(finished)
Pipe #2 : build(started) -> test -> deploy
 

Фактическое : Задания запускаются случайным образом из каждой трубы

 Pipe #1 : build(started) -> test -> deploy
Pipe #2 : build(waiting) -> test -> deploy

Pipe #1 : build(finished) -> test -> deploy
Pipe #2 : build(started) -> test -> deploy

Pipe #1 : build(finished) -> test -> deploy
Pipe #2 : build(finished) -> test(started) -> deploy

Pipe #1 : build(finished) -> test(started) -> deploy
Pipe #2 : build(finished) -> test(finished) -> deploy
 

Ответ №1:

вы можете определить resource_group , какие из них делают то же самое, disableConcurrentBuilds что и

 job:
  script: echo "test"
  resource_group: "group1"
 

видишь https://docs.gitlab.com/ee/ci/yaml/#resource_group

Комментарии:

1. я вижу, кроме того, единственное, что я могу порекомендовать,-это изменить управление версиями на более подходящий режим конвейера для артефактов, таких как «git description — теги-всегда-первый родитель». Таким образом, управление версиями всегда уникально для конвейера, и у вас нет проблем с артефактами-или вместо этого передайте артефакты как артефакты задания на следующий этап.

2. и у вас могут быть нижестоящие трубопроводы с группой ресурсов — смотрите docs.gitlab.com/ee/ci/yaml/…

3. resource_group работает на уровне задания, но не на уровне конвейера, мы уже пробовали это, но это не сработало, я добавил более подробную информацию о настройке нашего проекта и ожидаемом поведении в описание

4. но вы можете запустить дочерний конвейер — и использовать триггер для задания, которое его запускает — пожалуйста, прочитайте docs.gitlab.com/ee/ci/yaml/… — это покроет ваш случай использования. поскольку вы можете извлечь свою важную часть в дочерний конвейер и управлять распределением ресурсов и параллелизмом с помощью задания запуска