В этом уроке разберём два механизма, которые делают конвейер интерактивным: блок parameters - чтобы задавать вход сборки при запуске, и шаг input - чтобы поставить пайплайн на паузу прямо посреди выполнения и дождаться решения человека. Это база для параметризованного и ручного запуска в Jenkins, для аппрува деплоя в прод и для одного Jenkinsfile, который умеет катить в разные окружения. Build, на котором всё показываем, у нас 393.
Jenkins parameters: параметры сборки на входе
Параметры - это значения, которые ты задаёшь в момент запуска сборки, до того как пайплайн начнёт работать. Объявляются они в declarative-конвейере блоком parameters внутри pipeline. Как только в Jenkinsfile появляется этот блок, кнопка "Собрать" в интерфейсе превращается в "Собрать с параметрами" (Build with Parameters), и Jenkins показывает форму с полями.
Базовых типов несколько, и их хватает в 90 процентах случаев:
- string - однострочное текстовое поле. Версия, имя ветки, тег.
- choice - выпадающий список. Идеально для выбора окружения: dev, staging, prod. Первый элемент списка - значение по умолчанию.
- booleanParam - чекбокс. Прогнать ли тесты, делать ли пуш образа.
- password - поле, в котором ввод маскируется звёздочками в форме.
- text - многострочное поле для длинного текста.
Код: Выделить всё
pipeline {
agent any
parameters {
choice(
name: 'DEPLOY_ENV',
choices: ['dev', 'staging', 'prod'],
description: 'Куда катим'
)
string(
name: 'VERSION',
defaultValue: '1.0.0',
description: 'Версия артефакта'
)
booleanParam(
name: 'RUN_TESTS',
defaultValue: true,
description: 'Прогнать тесты перед сборкой'
)
}
stages {
stage('Info') {
steps {
echo "Окружение: ${params.DEPLOY_ENV}"
echo "Версия: ${params.VERSION}"
sh 'echo "Тесты включены: ${RUN_TESTS}"'
}
}
stage('Test') {
when { expression { params.RUN_TESTS } }
steps {
sh 'make test'
}
}
}
}
Важный нюанс первого запуска. Когда ты добавляешь блок parameters в Jenkinsfile, при первой сборке после изменения Jenkins ещё не знает про новые параметры - форму он покажет только со второго раза. Поэтому первый прогон после правки часто идёт со значениями по умолчанию. Это нормально, не баг.
Шаг input: ручной аппрув и пауза посреди пайплайна
parameters спрашивает на входе. А что, если нужно спросить человека в середине - после сборки и тестов, но перед выкаткой в прод? Для этого есть шаг input. Он останавливает конвейер и ждёт, пока кто-то нажмёт "Подтвердить" или "Прервать" в интерфейсе или в Pipeline Stage View.
Самый частый сценарий - ручной аппрув деплоя. Собрали, протестировали, прогнали стейджинг, а дальше пайплайн замирает и спрашивает у дежурного: "Катим в прод?" Никакой автоматики, решение за человеком.
Код: Выделить всё
pipeline {
agent any
parameters {
choice(name: 'DEPLOY_ENV', choices: ['staging', 'prod'])
}
stages {
stage('Build') {
steps { sh 'make build' }
}
stage('Deploy to staging') {
steps { sh './deploy.sh staging' }
}
stage('Approve prod') {
when { expression { params.DEPLOY_ENV == 'prod' } }
steps {
timeout(time: 30, unit: 'MINUTES') {
input(
message: 'Выкатить build 393 в прод?',
ok: 'Деплой',
submitter: 'lead,release-team'
)
}
}
}
stage('Deploy to prod') {
when { expression { params.DEPLOY_ENV == 'prod' } }
steps { sh './deploy.sh prod' }
}
}
}
Обязательно оборачивай input в timeout. Без таймаута сборка может висеть в ожидании вечно, занимая слот в очереди. С timeout по истечении времени input сам прервётся (по умолчанию с ошибкой), и сборка завершится - что обычно и нужно: не подтвердили за полчаса, значит не катим.
Возврат значений из input и параметры в Multibranch
input умеет не только спрашивать "да или нет" - он может вернуть значение. Если добавить внутрь блок parameters, человек на паузе выбирает вариант, и результат присваивается переменной. Когда параметр один, возвращается прямо его значение; когда несколько - map. Тут к месту scripted-вставка через script, потому что нужна динамика - присвоить результат и потом им пользоваться:
Код: Выделить всё
stage('Choose target') {
steps {
script {
def target = input(
message: 'Выбери цель деплоя',
ok: 'Поехали',
parameters: [
choice(name: 'REGION', choices: ['eu', 'us', 'asia'])
]
)
echo "Деплоим в регион: ${target}"
sh "./deploy.sh --region=${target}"
}
}
}
Где input ставить - на уровне stage или внутри steps - не формальность, а вопрос ресурсов. Если повесить input на агенте (внутри stage с agent), агент будет занят всё время ожидания и будет простаивать впустую. Поэтому стадию аппрува часто делают на отдельном лёгком агенте или вообще держат input так, чтобы тяжёлый агент освобождался на время паузы. В Kubernetes-сетапе с эфемерными pod-агентами это особенно заметно: держать pod живым полчаса ради ожидания клика - расточительно.
Про параметризованные сборки в Multibranch. Multibranch Pipeline берёт Jenkinsfile из каждой ветки и заводит отдельный job. Параметры здесь тоже работают: блок parameters в Jenkinsfile ветки даёт ту же форму "Собрать с параметрами". Тонкость в том, что Multibranch-джобы умеют запускаться автоматически по событию (push, обнаружение ветки), и при автозапуске форма не показывается - берутся значения по умолчанию. Ручной запуск (jenkins ручной запуск через "Собрать с параметрами") форму покажет. Поэтому для веток, которые катятся автоматически, держи вменяемые defaultValue, а интерактив через input оставляй для критичных стадий.
Типичные грабли
- Ждёшь форму параметров на первом прогоне после правки Jenkinsfile - её не будет, параметры регистрируются со второго запуска.
- input без timeout - зависшая навечно сборка, занятый исполнитель. Всегда оборачивай.
- Забыл submitter - аппрув прода может нажать кто угодно с доступом к Jenkins.
- input внутри stage с дорогим агентом - агент простаивает всё ожидание. Выноси паузу так, чтобы освобождать ресурсы.
- password-параметр - это не credentials. Значение всё равно попадает в конфиг job и в историю. Для настоящих секретов бери блок credentials и withCredentials, а password-параметр - только для разовых нечувствительных вводов.
- Сравнение booleanParam как строки. params.RUN_TESTS - это уже boolean, пиши when { expression { params.RUN_TESTS } }, без == 'true'.
Собери руками один Jenkinsfile:
- Добавь parameters: choice DEPLOY_ENV (dev, staging, prod), string VERSION, booleanParam RUN_TESTS.
- Запусти сборку дважды - убедись, что форма "Собрать с параметрами" появилась только на втором прогоне.
- Сделай стадию тестов условной через when и params.RUN_TESTS, проверь оба значения чекбокса.
- Добавь стадию аппрува с input, message про прод, ok "Деплой", submitter на свой логин, оберни в timeout 30 минут.
- Попробуй подтвердить под другим пользователем - кнопка не должна сработать. Дай таймауту истечь - сборка должна завершиться.
- Через input с parameters верни choice REGION и используй значение в sh-шаге.
- Через какой объект в declarative-пайплайне доступны значения параметров и почему форма не появляется на первом прогоне после правки?
- Зачем input оборачивают в timeout и что делает параметр submitter?
- Как из шага input вернуть выбранное пользователем значение в переменную?
- Чем password-параметр отличается от реальных credentials и где какой использовать?
parameters делает вход сборки гибким - одно окружение или другое, с тестами или без, без правки кода. input добавляет человека в петлю: пауза, ручной аппрув деплоя, выбор варианта прямо посреди пайплайна, с таймаутом и ограничением, кто может подтвердить. Вместе они превращают конвейер из жёсткого автомата в управляемый инструмент. На актуальных Jenkins LTS (линия 2.541.x в начале 2026, новый baseline 2.555 уже на Java 21/25) синтаксис тот же - declarative parameters и шаг input остаются стандартом. В следующих уроках это пригодится для безопасного выката в прод и для пайплайнов, которые разные люди запускают по-разному.
