Jenkins постоянно строит на подчиненном Windows даже без изменений в репозитории

Question

У меня есть два задания Jenkins, привязанные к конкретному ведомому устройству Windows, которые постоянно собираются.Они настроены на опрос Git SCM с выражением cron * * * * *, но будут собираться каждую минуту, даже если в репозитории Git не было никаких изменений.В журнале опроса Git для обоих заданий я вижу следующее:

Started on 20-Jan-2012 10:57:10
Using strategy: Default
[poll] Last Build : #4179
[poll] Last Built Revision: Revision 581837483fc583126d8fde7760c88062d3aa2cfa (origin/HEAD, origin/master)
Last build was not on tied node, forcing rebuild.
Done. Took 8 ms
Changes found

В частности, строка с надписью Last build was not on tied node, forcing rebuild. кажется подозрительной.Я вижу несколько сообщений о подобных вещах, когда гуглю этот термин, но решений нет.

У других ведомых Windows, похоже, нет такой же проблемы, поэтому я не уверен, что это чисто проблема Windows.

Кто-нибудь знает, что может вызвать это или что я могу сделать, чтобы решить эту проблему?

Answer 1

Хорошо, я только что решил это для нашего сервера сборки (под управлением Hudson) с помощью: http://web.archiveorange.com/archive/v/OkDctYWEcMGCgTIDY2Av

Когда вы связываете работу с подчиненной конфигурацией, в конфигурациизаписывается следующий файл

<assignedNode>hudson-slave1</assignedNode>

Когда сборка завершается, создается файл

<job>/builds/<build-no>/build.xml. 

Этот файл имеет

<builtOn>hudson-slave1</builtOn>

Я заметил одну странную вещь.Если вы видите ярлык, который я напечатал выше, он говорит «hudson-slave1», который принадлежит узлу «hudson-slave1».Как ни странно, узел «hudson-slave1» имеет две метки «build2» и «hudson-slave2».Нет такой метки «hudson-slave1» (см. Первое изображение). **

В нашем случае build был привязан к узлу «BUILDDEV3», который имел метку «major-builders».

Я добавил имя узла в список меток (изменив список меток на "major-builders BUILDDEV3"), и он сразу начал вести себя.

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

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

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

Answer 2

Я только что столкнулся с этой проблемой с Hudson v2.2.1 (да, я знаю, что это древняя версия). Я не уверен, что спровоцировало неконтролируемые сборки, поскольку никакие изменения конфигурации, по-видимому, не совпадают с началом сбегания. Однако я нашел (дополнительный) обходной путь.

На странице конфигурации задания есть опция (флажок) для «Ограничить, где этот проект может быть запущен», с двумя (радиокнопками) вариантами выбора средств ограничения: «Узел и меню метки» или « Расширенные выражения узлов и меток ", одно из которых должно быть выбрано.

Когда выбран второй из этих параметров «Расширенные выражения узла и метки», появляется текстовое поле произвольной формы, позволяющее ввести логическое выражение, объединяющее термины из

• набор имен подчиненных узлов ("BUILDDEV3" в ответе @ Campey), union
• набор всех значений меток подчиненных («основные строители» в ответе @ Campey).

Например, major-builders && !BUILDDEV3.

Когда выбран первый из этих параметров, «Узел и меню меток», появляется список выбора, который позволяет выбрать одно значение из списка, который содержит термины из:

• набор имен подчиненных узлов, union
• список всех значений меток подчиненных, объединение
• набор всех выражений, определенных в настоящее время в любом задании из механизма «Расширенные выражения узла и метки».

Обратите внимание, что набор имен подчиненных узлов по своей природе обрабатывается как метки подчиненных. Предложение @ Campey состоит в том, чтобы не связываться с механизмом выбора, а явно добавить имя подчиненного узла в список меток для каждого подчиненного устройства. Это будет работать, но имеет потенциальные побочные эффекты, скажем, если вы переименуете узел. Я не пробовал, но это может привести к появлению дубликатов в списке условий выбора для селектора отправки. Я предпочитаю избегать избыточного сбора информации.

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

Например, чтобы выразить пример, приведенный ранее: major-builders && !BUILDDEV3, где «major-builders» - это метка, а «BUILDDEV3» - это имя узла, необходимо добавить уникальную метку узла к узлу «BUILDDEV3». например «НИЧЕГО», а затем используйте выражение major-builders && !NOTHERE.

Answer 3

Вы абсолютно уверены, что работа была связана с рабом?

В качестве решения похожей проблемы с сообщением «Последняя сборка не была связана с узлом, принудительно перестраивать», было предложено связать работу с подчиненным узлом: https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&id=334069