Я работаю с одноузловым экземпляром Jenkins в проекте, где я хочу периодически очищать закрытые PR. Система может не отставать от средней скорости подачи PR; однако при повторном запуске репозитория сканирования для проекта система сталкивается с множеством параллельных сборок.
Когда мы запускаем репозиторий сканирования, многоотраслевой конвейер запускает отдельные этапы, которые обычно завершаются последовательно, без проблем и без истечения времени ожидания; однако приоритет декларативных действий после публикации кажется ниже, чем на других этапах (не установлены специальные плагины, которые могли бы вызвать AFAIK). Показанное поведение заключается в том, что параллельные сборки начинают работать, влияя на общее время выполнения для любой отдельной ветви или запроса на извлечение, так что все сборки могут указывать, скажем, время сборки 60 или 90 минут вместо обычных 6-10 минут, когда остается единственная задача заполняет отчеты контрольного стиля или любые второстепенные задачи по уведомлению.
Есть ли способ выделить один поток исполнителя на главном узле для декларативных действий после публикации, чтобы одна ветвь или PR могли быть запущены от конца к - не застревать в ожидании доступных исполнителей, которые неожиданно были выбраны для запуска другого PR или ветки и запуска более ранних (и дорогостоящих в вычислительном отношении этапов, таких как кодирование кода и выполнение модульных тестов), чтобы избежать в конечном итоге превышения времени ожидания?
![just waiting....](https://i.stack.imgur.com/UNBMb.png)