Я пытаюсь выяснить, как заставить блокировку ресурса Jenkins использовать динамически созданную метку блокировки, основанную на параметре задания и некотором дополнительном коде.
Общая проблема заключается в том, что я иметь сложный конвейер с несколькими последовательными и параллельными шагами, который должен быть заблокирован под одной блокировкой ресурса. Метка блокировки ресурса - это Dynami c, что является сложной задачей. В документации плагина блокировки ресурсов Jenkins сказано, что вы можете поместить несколько этапов в блок lock () {}, однако, похоже, это уже не так. Я могу получить только один скрипт для выполнения внутри блока lock () {}, поэтому кажется, что блокировка должна быть помещена в блок option {} этапа верхнего уровня. Проблема с размещением его в блоке option {} заключается в том, что кажется невозможным изменить какие-либо переменные, используемые внутри блока option {}, из блока конвейера {}.
Например:
lock_label = null
pipeline {
agent {
node {
label 'ci-runner-bionic'
}
}
stages {
stage('Setup') {
steps {
script {
lock_label = 'SOME_LOCK'
}
}
}
stage('World') {
options {
lock label: lock_label, resource: null, quantity: 2, variable: 'SERVERS'
}
stages {
stage('Something') {
steps {
sh 'echo "SERVERS=$SERVERS"'
}
}
stage('More things') {
parallel {
stage('Something 2') {
steps {
sh 'echo "SERVERS=$SERVERS"'
}
}
stage('Something 3') {
steps {
sh 'echo "SERVERS=$SERVERS"'
}
}
}
}
}
}
}
}
Когда этот конвейер действительно работает, метка блокировки, которую видит lock (), равна нулю, а не 'SOME_LOCK'. Несмотря на то, что перед блоком pipe {} может существовать код, который может повлиять на метку блокировки, проблема в том, что выполняемый ранее код не имеет доступа к параметрам, определенным в блоке pipe {}.
Я знаю, что есть HTTP-интерфейс для плагина блокировки. Тем не менее, выполнение этого может привести к утечке блокировок, поскольку нельзя гарантировать, что постблок будет выполнен, если есть какая-то всеобъемлющая проблема среды Jenkins или cra sh.