Спасибо. Нашел там инфу по тегам.

Всем привет, есть небольшой вопрос по организации запусков теста.
Значит тесты написаны на python крутятся в Jenkins, запускаются сьюты сразу после того как происходит merge c develop\master веткой, каждые сьюты гонятся для своего енва.
Проблема такова:
1. Сьюта гонится 50 минут
2. И merge request = запуск сьюты
3. Merge реквестов может быть штук 1-10 в течении часа

Проблема: после каждого мёржа вновь запускается сьюта с тестом, и так как они гонятся 50 мин, то выходит очень затратно это всё ждать)

Решение пока что вижу такое... Написать бота, дожидаться всех мержей от разрабов и просто с телеги командой посылать команду на jenkins api, чтобы он массового запустил все джобы с тестами для 1го прогона.
Может посоветуете ещё какие варианты?)

Перед запуском каждой джобы проверять, что текущий коммит является HEAD, иначе останавливать весь пайплайн.

Это не поможет

Каждый новый запуск запускается как раз на head. И в процессе не может узнать что head уже уехал

Единственное решение - отменять все предыдущие сборки, если запускается новая. Если я верно понял задачу

Сделать это можно через груви

Если в контексте запуска нет .git, то не сможет. А если есть, то достаточно сделать fetch.

Ты же не будешь каждую секунду делать фетч

Да и не сможешь

Перед запуском очередной джобы.

Ну вот это как вариант можно

Про Дженкинс не скажу, в Гитлабе это отлично рулится.

У каждой джобы свой воркспейс

Свой гит

Типа если сделал мерж 1, а затем сразу идёт мерж 2, то он быстро отменит мерж 1 и продолжит 2й?

Не имеет значения в контексте вопроса. Или я не понимаю, что ты хочешь сказать.

Запустилась новая сборка. Ты узнал что это новый хэд. Что дальше? Первая сама от этого не остановится, ее надо стопать принудительно

Да

Мы так делаем с пайплайнами на МР, когда пайплайн запускается на каждый коммит открытого МР