Чи можна «заблокувати» групу завдань через безліч трубопроводів gitlab


11

У мене кілька робочих місць, що працюють з одним зовнішнім ресурсом (сервером). Перше завдання розгортає додаток у середовищі, друге виконує тести в цьому середовищі, третє виконує тести інтеграції в цьому середовищі.

Я знаю, що є варіант групи ресурсів . Але він блокує лише робочі місця. Якщо два трубопроводи може працювати одночасно мені потрібно виконати job1, job2, job3від першого трубопроводу і тільки тоді , коли першого ресурсу виходу трубопроводу - другий трубопровід може почати jobs1-3. Чи є спосіб досягти цього? У трубопроводі є й інші завдання - вони повинні працювати одночасно.

Відповіді:


1

Налаштуйте спеціального бігуна для завдань1-3.

  1. Налаштуйте нового бігуна унікальним тегом, наприклад, 'jobs-1-2-3' та встановіть параметр concurrentto1 .

  2. Додайте унікальний тег, наприклад, "jobs-1-2-3" до відповідних завдань.

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

ІМХО це менше зусиль і надійніше.


Не впевнений, що це спрацює. Можливий сценарій: pipeline1 (p1) run task1 (j1), then pipeline2 (p2) run task1 (j1), then pipeline 1 start task2. Мені потрібно p1 run j1, j2, j3 тоді p2 run j1, j2, j3. Схоже, група ресурсів зробить те саме
Зуфар Мухамадєєв,

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

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

Так, бігун закінчить завдання в p1 перед тим, як обробити завдання з p2.
RiWe

Такий підхід працює поки що
Зуфар Мухамадєєв

0

Я думаю, що це може бути реалізовано за допомогою needsі resource_groupключових слів, і API gitlab.

Кожна робота отримує ідентифікатор трубопроводу, до якого вона належить predefined-variable. Якщо ви використовуєте gitlab api, ви можете побачити статус інших завдань у конвеєрі. Якщо ви можете використовувати цей статус 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.

(Я не перевіряв його сам, тому цей метод потребує перегляду.)

Референки:


Дякую за вашу відповідь. Якщо я зрозумів правильно в traffic_lightроботі, я повинен дочекатися завершення виконання завдання1-3 у паралельному трубопроводі. Що мені не подобається в такому підході - ваші ци хвилини будуть витрачені даремно на перевірку стану паралельного трубопроводу.
Зуфар Мухамадєєв

Якщо вас турбують ци-хвилини, для traffic_lightвикористання tagsключового слова ви можете скористатись власною організацією gitlab-runner . Сьогодні багато постачальників хмар надають безкоштовні екземпляри рівнів, яких достатньо для запуску простих завдань очікування traffic_light.
aluc

Схоже, що gitlab відраховує хвилини навіть у власних бігунів. Я намагаюся повторити роботу, на якій є тег для власників
Зуфар Мухамадєєв,

1
Якщо це пов’язано з цією проблемою ( gitlab.com/gitlab-org/gitlab-foss/isissue/58942 ), здається, що певний бігун не працює після перевищення квоти. Я не впевнений, чи це зрозуміло, але це не пов'язане безпосередньо з вашим початковим запитанням, тому я б запропонував опублікувати окреме питання тут або на gitlab.
aluc
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.