Назад | Перейти на главную страницу

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

Скажем, у меня есть задание Дженкинса «abc_job», которое в зависимости от определенных условий вызывает другое задание Дженкинса «xyz_job».

Теперь по некоторым причинам предполагается, что оба задания выполняются на одном подчиненном устройстве jenkins, что приводит к тупиковой ситуации, поскольку задание «abc_job» запускает «xyz_job», а «xyz_job» ожидает, пока «abc_job» освободит для него подчиненное устройство jenkins. чтобы начать работать.

Как преодолеть такой сценарий?

Есть три способа обойти это, о которых я знаю и которые я использовал в прошлом. Какой из них лучше, зависит от вашей конкретной ситуации.

  • Добавьте больше слотов для исполнителей. Вы также можете поиграть с метками исполнителей и ограничить сборки определенными метками, чтобы всегда был свободный слот исполнителя для вашей последующей работы, но это сложно сделать правильно.
  • Не ждите, пока закончится последующая работа. Запустите сборку с помощью build(wait: false, job: ...). Родительское задание завершится немедленно, вместо того, чтобы использовать слот исполнителя, пока оно ожидает нисходящего потока. Следствием этого является то, что родительская сборка не завершится неудачно, если последующая сборка завершится неудачно.
  • Не звони build() внутри node { } блок. Код вне блока узла выполняется на мастере и не занимает слот исполнителя. Однако я считаю, что это возможно только в том случае, если вы используете скриптовый конвейер, а не декларативный.