Можно ли «заблокировать» группу заданий по нескольким конвейерам 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.