Должны ли шаги сборки быть долговечными, чтобы работать параллельно с рабочим процессом Jenkins?

Question

Я экспериментирую с параллельным шагом в рабочем процессе Дженкинса. В настоящее время мой поток выглядит (по сути) так:

parallel 'Deploy-A-Machine': {
    node {
        input 'Shall we deploy the A machine?'
        step([$class: 'DeployMachineBuilder', deploymentName: aPodName])
    }
}, 'Deploy-B-Machine': {
    node {
        input 'Shall we deploy the B machine?'
        step([$class: 'DeployMachineBuilder', deploymentName: bPodName])
    }
}

Оба входа отображаются как запущенные на разных исполнителях, но когда я нажимаю "продолжить" на обоих, фактически запускается только первое развертывание. Развертывания запускаются как пользовательский плагин, который был написан для устаревших заданий и минимально преобразован в рабочий процесс. Я не вижу очевидного сообщения об ожидании исполнителя, развертывание просто не начинается. Как только первый закончен, второй немедленно начнется.

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

Answer 1

Если предположить, DeployMachineBuilder это SimpleBuildStep Вы написали, действительно его perform Метод просто блокирует виртуальную машину Workflow на время ее работы: интерпретатор Groovy использует многозадачность для совместной работы.

Самым простым решением, где это возможно, является использование sh шаги, а не пользовательский строитель. Это переживает отключение подчиненного устройства и / или перезапуск Jenkins, отображает постепенный прогресс и правильно работает с parallel, JENKINS-26055 предоставит более удобный способ определения пользовательских "длительных" шагов. JENKINS-25879 предоставил бы более удобный способ определения шагов, которые не являются долговременными, но, по крайней мере, избегают блокировки собственного потока (так что ведите себя лучше в parallel и войти постепенно).

Кстати, в вашем примере сценария я бы порекомендовал переместить input выйти за пределы node блок: нет смысла задерживать исполнителя, ожидая (возможно, неопределенно) одобрения пользователя.