Привет. Есть Teamcity, который на каждый пулл реквест в гите

запускает деплой стейджинга в кубер и затем E2E тесты.
Если разработчик делает несколько пушей с интервалом в 5 минут, то на одном стейдже может запуститься несколько Е2Е одновременно и они начинают мешать друг другу.
Я хочу ограничить, чтобы одновременно для одной ветки мог работать только 1 билд с E2E, а остальные висели в очереди. Как мне этого добиться?

Ограничение "number of simultaneously running builds" влияет на всю конфигурацию целиком, а мне нужен лимит per branch.
Этого можно было бы добиться через Shared Resouce with Custom Value, вешая лок на каждую ветку, но все возможные custom values надо объявить заранее, а в билде я не могу указать зависимость от ресурса, взяв его value из переменной.

У кого-нибудь есть идеи, как это можно решить?

В голову приходит только Quiet period + проверка не бежит ли на агентах билд с этого же бранча

Quiet period я не могу такой долгий ставить. Прогон текущих тестов занимает 15 минут и будет только расти. А проверка, не бежит ли на агентах билд с этого же бранча на каком уровне должна работать? Если как шаг внутри билда, то я же не смогу его переставить в очередь. То есть разработчик пушит в гит, код деплоится, затем запускается билд E2E, видит что работает другой для той же ветки, запущенный 10 минут назад, и что он должен сделать? Тут два варианта - прибиться, но тогда тесты для кода не запустятся. Или впасть в цикл ожидания, но тогда агенты будут проставить впустую.

хммммм... период я имел вв виду пока пользователь все догрузит что хотел

ну он сейчас стоит в 60 секунд. а разработчик бывает через 5-10 минут следюущий коммит делает.

Мне кажется, тебе на ограничивать не количество одновременных билдов, а количество одновременных e2e тестов - каким-то местным локом

ну это опять же фактически блокирует агенты, которые будут висеть уже подхватив билд и в ожидании лока.

Просится решение - две разных билд конфигурации. Одна билдит и деплоит, другая тестит. И триггеры у них значит разные должны быть.

Так оно сейчас так и есть. Одна билдит и деплоит после пуша в гит, вторая тестит после деплоя. Но это не мешает двум тестам запуститься в итоге одновременно с некоторым интервалом. На самом деле мне надо, чтобы второй билд не запускался пока тест первого не закончится, но я решил не усложнять постановку задачи

временное окно и запускать тест только на последнем коммите. или важно прямо каждый прогонять?

Варик - результаты теста складывать в артефактори. Тригерить новый билд по обновлению артефактори

Временное окно стоит минуту. Тест длится 15 минут. А временное окно в 15 минут - слишком долго. Плюс тест может запуститься не сразу, если есть накопленная очередь на агентах. и тогда между коммитами может быть еще больше гап, чтобы тесты запустились одновременно

смотри коммит А1 триггерит деплой А1, который триггерит тест А1 коммит А2 триггерит деплой А2, который триггерит тест А2 я не могу деплой А2 триггерить на появление артефакта после теста А1, потому что они логически не связаны между собой.

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

Я имел в виду - что тесты триггерятся только результатами тестов. Билд триггерится коммитом. Деплой триггерится результатами билда.

но триггерить тест А2 на появление артефакта А1 тоже логически неверно. Они не связаны. На момент окончания А1 А2 может не быть вообще. Он может появиться через неделю только А1 и А2 - это идентификаторы коммитов, если что

инициатором всех событий является пуш в гит. разработчик пушит код в ветку, для которой создан пулл реквест -> Срабатывает вебхук в гите, который говорит в тимсити об обновлении ветки -> Тимсити билдит для нового коммита контейнеры -> загружает их в докер реджистри -> создает/обновляет deployment в k8s -> завершает билд деплоя завершение билда деплоя триггерит запуск E2E тестов на задеплоенном стейджинге И вот пока эти тесты не закончились, разработчик делает новый пуш в гит и триггерит эту цепочку заново. Она приводит к параллельному запуску другой серии тестов на том же стейдже, а это приводит к некорректным результатам тестов.