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

Question

Итак, большинство вопросов и ответов, которые я нашел по этому вопросу, предназначены для людей, которые хотят использовать ТО ЖЕ рабочее пространство для разных прогонов. (Это сбивает меня с толку, но тогда мне нужно каждый раз, когда я начинаю работу, требовать чистого листа. Оставшиеся вещи только сломают вещи)

Моя проблема - ТОЧНАЯ противоположность - у меня ДОЛЖЕН есть отдельное рабочее пространство для каждого прогона (или мне нужно знать, как создавать файлы с одинаковыми именами в разных прогонах, которые остаются только для этого прогона, и которые легко доступны из скриптов bash, запущенных конвейером!)

Итак, мой вопрос - как я могу заставить Дженкинс НЕ использовать одно и то же рабочее пространство для двух одновременно выполняемых заданий на разных хостах, ИЛИ какую переменную я могу использовать в поле «настраиваемое рабочее пространство» для достижения этой цели?

После того, как я ответил на вопрос @Joerg S, я понял, что говорю то, что, как говорит Йорг S, НЕ МОЖЕТ произойти, это ТОЧНО то, что я наблюдаю! Дженкинс использует одно и то же рабочее пространство для двух разных параллельных заданий на двух разных хостах. Это ошибка конвейера Дженкинса?

См. Ниже ошеломляющее количество информации.

Учитывая то, как мне нужно заходить и выключать узлы во время выполнения, я обнаружил, что могу запустить 2 разных сборки на разных хостах одной и той же работы, и они ПОДЕЛЯЮТСЯ каталогом рабочей области! Поскольку каждое задание имеет сценарии оболочки, которые заняты записью файлов в этот каталог, это очень плохо.

В Настраиваемое рабочее пространство в jenkins Нам сказали использовать настраиваемое рабочее пространство, и я настроен именно так

В Дженкинс: как запускать сборки в уникальных каталогах нам сказано использовать $ {BUILD_NUMBER} в указанном выше поле настраиваемого рабочего пространства, поэтому я попытался:

 ${JENKINS_HOME}/workspace/${ITEM_FULLNAME}/${BUILD_NUMBER}

Все, что происходит со мной, когда я использую, это то, что имя рабочей области, как вы уже догадались, "$ {BUILD_NUMBER}" (а я даже получил "$ {BUILD_NUMBER} @ 2" просто для примера!)

Я попробовал {$ BUILD_ID}, тоже самое (использует буквально, а не подставляет число).

У меня включена функция «разрешать одновременные сборки».

Я использую исключительно конвейеры.

Все задания здесь, как часть обычного выполнения, приводят к тому, что ведомый хост, не являющийся главным, перезагружается в ОС, которая не имеет возможности запускать slave.jar (действительно, он вообще не имеет доступа к сети), поэтому Я не могу запустить весь конвейер на этом хосте.

Все задания используют следующую конструкцию где-то внутри них:

    tests=Arrays.asList(tests.split("\\r?\n"))
    shellerror=231
    for( line in tests){

Итак, давайте назовем примерное задание 'foo', которое проходит по списку, как указано выше, которое я хочу запустить на 2 разных хостах. Конвейер для этого задания начинает работать на главном (так как выше для (строка в тестах) ТРЕБУЕТСЯ для запуска на узле!)). Затем переходит туда и обратно между хозяином и рабом, часто несколько раз.

Если я начну эту работу на хосте A и хосте B примерно в одно и то же время, они ОБА будут использовать рабочее пространство $ {JENKINS_HOME} / workspace / $ {JOB_NAME} или в моем случае / var / lib / jenkins / jenkins / рабочее пространство / работа

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

Итак, как заставить Дженкинса использовать уникальное рабочее пространство КАЖДУЮ ОДИН РАБОТА?

Или что ???

Другое: шаг сборки конвейера версия 2.5.1, Jenkins 2.46.2

Я пытался заставить оператор рабочей области ('ws') работать, но это тоже не совсем так, как я ожидал - некоторые файлы находятся в рабочей области, которую я явно назвал, а некоторые все еще находятся в ' встроенное рабочее пространство (workspace /).

Меня попросили предоставить код. «Стандартный» конвейер, который я использую, составляет около 26K байтов, составляя около 590 строк. Итак, я собираюсь сильно уменьшить. Как говорится:

node("master") { // 1
   ..... lots of stuff....
}  // this matches the "node('master')" above
node(HOST) {
  echo "on $HOST, check what os"
  if (isUnix()) 
      ...some more stuff...
} // end of 'node(HOST)' above
if (isok == 0 ) {
   node("master") { 
      echo "----------------- Running on MASTER 19 $shellerror waiting on boot out of windows ------------"
      sleep 120
      echo "----------------- Leaving MASTER ------------"
   }
}
 ... lots 'o code ...

node(HOST) {
  ... etc 
} // matches the latest 'node HOST' above
node("master") { // 120
    .... code ...
    for( line in tests) {
        ...code...
    }
}
... and on and on and on, switching back and forth from one to the other

FWIW, когда я попытался использовать вышеприведенное использование «ws», чтобы убедиться, что имя ws уникально, я просто добавил блок «ws wsname» непосредственно под (почти) каждым открытием «узла», чтобы оно было

node(name) { ws (wsname) { ..stuff that was in node block before... } }

Но тогда у меня есть две директории, о которых нужно беспокоиться о проверке - и рабочая область по умолчанию / имя_папки dir, и новая wsname.

Answer 1

Попробуйте использовать customWorkspace общий параметр узла:

pipeline {
  agent {
    node {
      label 'node(s)-defined-label'
      customWorkspace "${JENKINS_HOME}/workspace/${JOB_NAME}/${BUILD_NUMBER}"
    }
  }
  stages {
    // Your pipeline logic here
  }
}

customWorkspace

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

Редактировать

Так как это не работает для вашего сложного конвейера. Может быть, попробуйте это глупое решение:

def WORKSPACE = "${JENKINS_HOME}/workspace/${JOB_NAME}/${BUILD_NUMBER}"

node(HOST) {
   sh(script: "mkdir -p ${WORKSPACE}")
   sh(script: "cd ${WORKSPACE}")
   //Do stuff here
}

или если dir () доступен:

def WORKSPACE = "${JENKINS_HOME}/workspace/${JOB_NAME}/${BUILD_NUMBER}"

node(HOST) {
   sh(script: "mkdir -p ${WORKSPACE}")
   dir(WORKSPACE) {
   //Do stuff here
   }
}

Answer 2

'${SOMEVAR}'

не заменится

"${SOMEVAR}"

воля - это то, как обрабатываются нестандартные строки см. обработка цепочек

так что если у вас есть

ws("/some/path/somewhere/${BUILD_ID}")
{
   //something
}

на вашем узле в вашем конвейере Jenkinsfile это должно сработать в этом отношении

проблема с рабочими пространствами @ 2 может возникать, когда вы разрешаете параллельные сборки проекта - у меня была точно такая же проблема с пользовательским ws () с @ 2 - просто запрещаете параллельные сборки или обходите это.