Можно ли «заблокировать» группу заданий по нескольким конвейерам gitlab?


11

У меня есть несколько заданий, работающих с одним внешним ресурсом (сервером). Первое задание развертывает приложение в среде, второе выполняет тесты в этой среде, третье выполняет интеграционные тесты в этой среде.

Я знаю, что есть опция группы ресурсов . Но это блокирует только рабочие места. Если два трубопровода может работать одновременно мне нужно выполнить job1, job2, job3от первого трубопровода и только тогда , когда первого ресурса выхода трубопровода - второй трубопровод может начать jobs1-3. Есть ли способ добиться этого? Есть другие рабочие места в процессе - они должны работать одновременно.

Ответы:


1

Настройте выделенного бегуна для заданий 1-3.

  1. Установите нового бегуна с уникальным тегом, например, «jobs-1-2-3», и установите опцию concurrentна1 .

  2. Добавьте уникальный тег, например, «jobs-1-2-3» к рассматриваемым вакансиям.

    job1:
      tags:
        - jobs-1-2-3
    job2:
      tags:
        - jobs-1-2-3
    job3:
      tags:
        - jobs-1-2-3
    

ИМХО это меньше усилий и надежнее.


Не уверен, что это сработает. Возможный сценарий: конвейер1 (p1) выполнить задание 1 (j1), затем конвейер2 (p2) запустить задание 1 (j1), затем конвейер 1 запустить задание2. Мне нужно p1 запустить j1, j2, j3, затем p2 запустить j1, j2, j3. Похоже, ресурсная группа поступит так же
Зуфар Мухамадеев

Поскольку новый исполнитель будет обрабатывать только одно задание за раз, и из-за уникального тега другой исполнитель не выберет задания, то гарантируется, что p2 ожидает завершения p1. Также см. Docs.gitlab.com/ee/user/project/pipelines/…
RiWe

Я не хочу отменять ожидающие конвейеры. Как я уже сказал, есть другие рабочие места - они должны работать одновременно. Так что вы говорите, если работают два конвейера и установлена ​​параллельная опция - бегун всегда будет выбирать задания из первого конвейера?
Зуфар Мухамадеев

Да, бегун завершит задания в p1 перед обработкой заданий из p2.
RiWe

Этот подход работает до сих пор
Зуфар Мухамадеев

0

Я думаю , что это может быть реализован через needsи resource_groupключевые слова и gitlab API.

Каждое задание получает идентификатор конвейера, которому оно принадлежит как predefined-variable. Если вы используете API gitlab, вы можете увидеть состояние других заданий в конвейере. Если вы можете использовать этот статус needsи resource_groupключевые слова, я думаю, вы можете достичь того, что вы хотели. Смотрите описание кода ниже и его комментарии для более подробной информации.

stages:
  - ready
  - build

job1:
  stage: build
  needs: [starting_signal]
  script: 
    - sleep 10 && echo "job1"
job2:
  stage: build
  needs: [starting_signal]
  script:
    - sleep 20 && echo "job2"
job3:
  stage: build
  needs: [starting_signal]
  script:
    - sleep 30 && echo "job3"

starting_signal:
  stage: ready
  script:
    - # TODO: You need to implement it using the GitLab API.
    - # The starting condition for "job1-3" is
    - # that this `starting_signal` job finished successfully.
    - # And the condition that ends with the success of this job
    - # is that `traffic_light` becomes running.

traffic_light: 
  stage: ready
  resource_group: traffic_light
  script:
    - # TODO: You need to implement it using the GitLab API.
    - # The end condition for `traffic_light` is
    - # the end of job1-3 execution.
    - # In other words, this job must be checked and waited
    - # through gitlab api until job 1,2,3 is finished.
    - # Since this job locks the execution of a `traffic_light` job
    - # in another pipeline, the `starting_signal` job in another 
    - # pipeline does not succeed.

(Я не проверял это сам, поэтому этот метод нуждается в обзоре.)

Referenecs:


Спасибо за Ваш ответ. Если я правильно понял в traffic_lightзадании, я должен дождаться окончания выполнения задания 1-3 в параллельном конвейере. Что мне не нравится в этом подходе - ваши минуты будут потрачены на проверку состояния параллельного конвейера.
Зуфар Мухамадеев

Если вы обеспокоены či минут, вы можете использовать самопринятый gitlab-раннер для traffic_lightиспользования tagsключевого слова. Сегодня многие поставщики облачных услуг предоставляют бесплатные экземпляры уровней, которых достаточно для выполнения простых заданий ожидания, таких как traffic_light.
aluc

Похоже, Гитлаб считает минуты даже у бегунов, которые принимают себя самостоятельно. Я пытаюсь повторить задание с тегом для самостоятельного бегуна - но он не запускается и показывает сообщение о превышении лимита конвейера: i.imgur.com/vBftxmk.png
Зуфар Мухамадеев

1
Если это связано с этой проблемой ( gitlab.com/gitlab-org/gitlab-foss/issues/58942 ), похоже, что определенный бегун не работает после превышения квоты. Я не уверен, что это понятно, но это не имеет прямого отношения к вашему первоначальному вопросу, поэтому я бы предложил опубликовать отдельный вопрос здесь или на gitlab.
aluc
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.