Fix: Этап распаковки не должен выполняться параллельно, чтобы не было ошибок работы сервера при единовременном запуске

[Kyrales]

На этапе "Проверка качества" одновременно стартует параллельный этап разных проверок "Распаковка ИБ". Если это выполняется на одном сервере, то может приводить к ошибкам из-за пиковой нагрузку. Плюс из за практически одновременного завершения этапа "Распаковка ИБ" (если все ок), стартую следующие тяжелые процессы.

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

[Segate-ekb]

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

[Kyrales]

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

@Segate-ekb тут как раз нужно, чтобы была параллельность, а если запретим воркеру работу в параллельности, то это уже совсем другое. Затраты на ожидания обычно не значительные при распаковки, но мы заведомо страхуемся от пиковых загрузок.

[ovcharenko-di]

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

В крайнем случае можно сделать условный lock, значение которого зависит от параметра (см. реализацию в где-то Coverage). Но я считаю, что по умолчанию блокировка не должна устанавливаться.

[nixel2007]

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