Почему Дженкинс иногда без необходимости переходит на другой узел?

avatar
O'Rooney
9 августа 2021 в 03:29
47
1
0

Почему Jenkins меняет узел, чтобы выполнить другую сборку, когда в этом нет необходимости?

У нас есть установка Jenkins с 3 узлами Mac и 3 узлами Windows, мы создаем проекты в свободном стиле. Мы не используем мастер для сборки. Проекты настроены для работы на любом из 3 узлов, подходящих для их платформы. Для этой цели мы используем ярлыки.

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

Jenkins утверждает, что при наличии нескольких возможностей следует распределять задания на один и тот же узел, если это возможно.

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

В настоящее время версия Jenkins – 2.289.2.

Задания представляют собой произвольные сборки с шагами сценария оболочки/командной строки.

Репозитории Git и Mercurial.

Источник

Ответы (1)

avatar
Sreevathsabr
9 августа 2021 в 03:58
0

Я думаю, что если вы прочитаете Restrict where this project can be run, это может дать вам ответ на ваш вопрос.

Как сказано в его определении By default, builds of this project may be executed on any agents that are available and configured to accept new builds. Поэтому, если вы не укажете агент и ограничите запуск сборки определенным узлом, он будет выбран случайным образом.

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

Только для решения вышеуказанной проблемы у нас есть функция Restrict where this project can be run в Jenkins. Пожалуйста, посмотрите на скриншот ниже для получения подробной помощи, которую мы можем получить в Jenkins.

enter image description here

Sreevathsabr
9 августа 2021 в 10:26
0

поэтому переопределение означает указание узла в Restrict where this project can be run

Ian W
9 августа 2021 в 10:34
2

За исключением того, что «По умолчанию Jenkins пытается выделить задания последнему узлу, на котором было выполнено (ref.)». Итак, что-то происходит с OP, переопределяющим это, «даже если ранее использованный узел доступен и не занят». Вопрос в том, почему, чтобы не переопределить результат.

O'Rooney
10 августа 2021 в 04:27
0

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

O'Rooney
10 августа 2021 в 04:34
0

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

Sreevathsabr
10 августа 2021 в 04:37
1

@ О'Руни, я не голосовал против. Я не знаю, кто это сделал. Но документ Яна очень интересный и противоречит тому, что написано в справке Дженкинса. Я только что проголосовал, так что будет интересно понять