#jenkins
Вопрос:
Почему Дженкинс меняет узел для выполнения другой сборки, когда в этом нет необходимости?
У нас есть установка Дженкинса с 3 узлами Mac и 3 узлами Windows, создающими проекты в свободном стиле. Мы не используем мастер для сборки. Проекты настроены для запуска на любом из 3 узлов, подходящих для их платформы. Для этой цели мы используем этикетки.
В некоторых случаях, когда мы выполняем сборку, она будет выполняться на том же узле, что и в прошлый раз. Но иногда, без какой-либо очевидной закономерности, он будет меняться на другой узел, даже если ранее используемый узел доступен и не занят. Это потенциально отнимает много времени, поскольку инкрементные сборки на одном и том же узле выполняются намного быстрее, чем извлечение и создание всего с нуля.
Дженкинс утверждает, что он должен распределять задания на один и тот же узел, если это возможно, когда существует несколько возможностей.
В результате, с точки зрения пользователя, это выглядит так, как будто Дженкинс пытается всегда использовать один и тот же узел для одной и той же работы, если он недоступен, и в этом случае он будет создаваться в другом месте. Но как только предпочтительный узел доступен, сборка возвращается к нему. Ссылка
Версия Дженкинса в настоящее время составляет 2.289.2.
Задания являются сборками в стиле фристайла с шагами сценария оболочки/командной строки.
Репозитории Git и Mercurial.
Ответ №1:
Я думаю, что если вы прочтете 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 функция в Дженкинсе. Пожалуйста, посмотрите на скриншот ниже для получения подробной помощи, которую мы можем получить в Дженкинсе .
Комментарии:
1. таким образом, переопределение означает указание узла в
Restrict where this project can be run2. За исключением того, что «По умолчанию Дженкинс пытается выделить задание последнему узлу, на котором было выполнено ( ссылка)». Итак, что-то происходит с переопределением операции, «даже если ранее используемый узел доступен и не занят». Вопрос в том, почему, а не для того, чтобы переопределить результат.
3. Именно Йен. Я не хочу ограничивать его только одним узлом, потому что это означает, что он вообще не может работать, когда узел занят чем-то другим. Я просто хочу, чтобы он оставался на одном и том же узле, когда это возможно.
4. Я уточнил, что ожидаю, что задокументированное предпочтение Дженкинса останется на том же узле. Я согласен, что без этого документа можно было бы ожидать, что он просто случайным образом выберет один из них.
5. @O’Rooney Я не голосовал против. Я не знаю, кто это сделал.. Но документ Яна очень интересен и противоречит тому, что написано в справке Дженкинса . Я только что проголосовал , так что будет интересно понять