Как конвейерные сборки Jenkins определяют папку рабочей области?

Question

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

Но ... Как именно создается путь к рабочей области?

Наша сборка назначена конкретному узлу (с 4 исполнителями) и настроена на запрет одновременных сборок.Обычно это было присвоено:

EXECUTOR_NUMBER=1
WORKSPACE=xxx\yyy\jobname

В какой-то момент сборка начала выполняться на исполнителе 2, но все еще использовала то же рабочее пространство, что и раньше.

Позже сборка снова выполнялась на исполнителе 1, но теперь использовалась

WORKSPACE=xxx\yyy\jobname@2

, которая прервала сборку, поскольку она не может обработать знак «@» в пути.С этого момента сборка продолжала использовать это рабочее пространство, даже после установки числа исполнителей на машине сборки равным 1, ручного удаления каталога рабочей области агента и т. Д.

Итак, мои вопросы:

• Как точно определяется путь к рабочей области?Почему он получает суффикс @ 2 внезапно?
• Дженкинс повторно использует предыдущее рабочее пространство, независимо от номера исполнителя?
• Если да, где хранится эта информация?Я не смог найти ничего в конфигах работы, связанных с последним использованным путем к рабочей области ...

Спасибо за любые идеи!

Мы используем Jenkins LTS 2.107.2 и вышесовременные плагины для Pipeline (я не знаю, какая версия представляет особый интерес).

Answer 1

Распределение рабочего пространства выполняется в WorkspaceList.java .

В рабочей области могут быть получены блокировки, которые затем приводят к суффиксу @<number>, см. Метод allocate, в котором указывается This method doesn't block prolonged amount of time. Whenever a desired workspace is in use, the unique variation is added. Проверьте в конце переменную COMBINATOR.

Если это действительно такая большая проблема, вы можете сами скомпилировать jenkins и изменить этот разделитель.Меньше хлопот, вероятно, будет выделять рабочие пространства самостоятельно, то есть выбирать свои собственные пути, хотя каким-то образом проверяя, что они не используются (или используя некоторый суффикс временной метки), но имейте в виду, что этот разделитель также используется для некоторых других путей, которые могут использоваться, например, когдаиспользуя глобальные общие библиотеки , в которых используются такие пути, как workspace@script и т. д.

Редактировать: пропущены другие ваши вопросы.Как вы можете видеть в этом исходном файле, номер исполнителя не имеет значения для именования рабочей области.Единственная причина в том, что какая-то блокировка находится на пути к базовой рабочей области без суффикса + число (inUse.get(candidate.getRemote());. Поэтому, как только рабочая область используется, она просто проверит следующего кандидата с помощью @n+1 Насколько я знаю, Дженкинс будет повторно использовать рабочие области. В зависимости отвашей стратегии извлечения scm вы можете даже подумать о ручной очистке рабочего пространства перед сборкой с помощью deleteDir , просто чтобы не получить побочных эффектов.

Answer 2

рабочие пространства не должны влиять на ваш конвейерный скрипт.

в моей работе я просто делаю

def workspace = pwd()

в начале области видимости узла и использует рабочую область как переменную, и она работает как шарм.

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

dir (worspace){
 do something
}

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

Надеюсь, это поможет