Comments 4
Допустим, задачи выполняются за сильно разное количество времени, тогда, если мы вдруг имеем решение с параллельностью и ограничением количества тредов, где задачи просто берутся из кучи в неотрегулированной последовательности, то всё равно, велика вероятность, что n-1 задач, будучи раскиданы по тредам, выполнятся примерно за одинаковое количество времени, а последняя окажется очень долгая и её надо будет ждать одну.
Мне кажется, если уж говорить о полном решении с параллельностью, то нужно заранее знать, за сколько единиц времени выполняется каждая задача из списка, и уже на основе этой информации раскидывать по тредам. Или, если пытаться в какую-то автоматизацию, то новый плагин (или доработка старого), который будет сам смотреть время выполнения стейджей в предыдущих запусках конкретной джобы и уже на этом строить наполнение потоков.
Согласен. Балансировка никакой здесь нет. Задачи берутся просто по очереди. На практике иногда так и получается, что в конце остаются 4-5 долгих задач, которые неплохо было бы запустить пораньше. Задача по балансировка есть, и скорее всего алгоритм будет улучшен в будущем. Но даже такое решение отлично подходит для решения нашей задачи.
Достаточно простым расширением функции, мне кажется, выглядит - взять продолжительность (среднее или что-то другое) каждой из стейджей на основе N предыдущих билдов (вот тут пример, как можно сделать https://stackoverflow.com/questions/52322290/capture-time-taken-by-each-pipeline-stage-in-jenkins/64215781#64215781) и, уже на основе этих данных, раскидать по потокам.
Будут моменты, которые надо будет решить, как что делать с новыми стейджами или если какой-то стейдж только падал... Но тут достаточно, мне кажется, просто "придумать" правило, какое время ему давать для передачи в функцию распределения по тредам.
Круто, очень полезная информация. Если найдете ещё варианты, поделитесь пожалуйста
Как ограничить количество выполняющихся задач в Jenkins при вызове parallel: сравниваем решения