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