Три кита: node, stage и steps
Любой Jenkins pipeline отвечает на три вопроса, и каждому соответствует своя сущность DSL.
- Где выполнять - это node (узел) в терминах scripted-конвейера или директива agent в declarative. Jenkins node - это контроллер или, чаще, отдельный агент, на котором реально крутятся твои команды. Контроллер дирижирует, агенты пашут. Когда ты пишешь agent any, ты говоришь: "запусти на любом свободном исполнителе".
- Логический этап - это stage. Build, Test, Deploy - вот типичные jenkins stage. Каждый stage - это именованный блок, который Jenkins отдельно рисует в интерфейсе. Видишь зелёную или красную плитку в Stage View - это и есть твой stage. Этапы нужны людям: с одного взгляда понятно, на чём сборка упала.
- Конкретные шаги - это steps. Внутри stage живут jenkins steps: вызвать shell, напечатать сообщение, забрать код из git. Шаг - это атомарная операция. echo печатает строку в лог, sh выполняет команду оболочки. Из таких кирпичей и складывается работа.
Declarative как стандарт 2026: каркас pipeline
В 2018 году спорили, что брать - scripted (чистый Groovy) или declarative. В 2026 спор закрыт: declarative pipeline - выбор по умолчанию. Он строже, понятнее, его валидирует линтер, и он покрывает 95 процентов задач. Scripted берём только там, где нужна реальная динамика: генерить стейджи в цикле, сложные условия на Groovy. Для всего остального - declarative.
Минимальный каркас, который надо выучить наизусть:
Код: Выделить всё
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Собираю проект'
}
}
}
}
Важно про среду 2026: Jenkins давно ушёл от терминов master и slave. Теперь это контроллер (controller) и агент (agent). Если в старых статьях видишь node как "slave" - это устаревший словарь. Сам Jenkins на актуальной LTS-линии (ветка 2.541.x, а свежий baseline 2.555.1) уже требует Java 21 как минимум - Java 17 с начала 2026 года не поддерживается. Это к тому, что примеры из книги 2018 года надо мысленно переносить на современную базу.
Jenkins pipeline пример: первый конвейер от checkout до тестов
Теперь полноценный jenkins pipeline example с тремя стейджами. Это не псевдокод, а рабочий Jenkinsfile для типового приложения. Подставь свои команды сборки - и поедет.
Код: Выделить всё
pipeline {
agent any
options {
timestamps()
timeout(time: 20, unit: 'MINUTES')
}
stages {
stage('Checkout') {
steps {
checkout scm
echo "Ветка: ${env.BRANCH_NAME}"
}
}
stage('Build') {
steps {
sh 'make build'
}
}
stage('Test') {
steps {
sh 'make test'
}
post {
always {
junit 'reports/**/*.xml'
}
}
}
}
post {
success {
echo 'Конвейер прошёл успешно'
}
failure {
echo 'Сборка упала, смотри лог стейджа'
}
}
}
Директива options сверху - это глобальные настройки: timestamps() добавляет время к каждой строке лога (бесценно при разборе зависаний), timeout прибьёт сборку, если она висит дольше 20 минут. Финальный post на уровне pipeline реагирует на общий итог: success или failure.
Как читать вывод и Stage View. После запуска открой страницу сборки. Раздел Stage View (он же стейдж-вью) покажет горизонтальную ленту плиток - по одной на каждый stage. Зелёная - этап прошёл, красная - упал, время в плитке - сколько он длился. Кликаешь на красную плитку и проваливаешься прямо в лог этого этапа, не листая весь вывод. Полный текстовый лог - в Console Output. Старый плагин Blue Ocean, который раньше рисовал красивые конвейеры, сейчас фактически заброшен и не развивается - не строй на нём процессы, штатного Stage View и Pipeline Graph View хватает.
Типичные грабли
- steps забыли, пишут команды прямо в stage. Внутри stage обязателен блок steps (в declarative). Голый sh внутри stage без steps - ошибка. Это самая частая опечатка новичка.
- Путают echo и println. В declarative для печати используй шаг echo, а не Groovy-шный println - последний работает, но это уже выход в scripted-территорию.
- Кавычки в sh. Двойные кавычки в Groovy раскрывают переменные (${env.BRANCH_NAME}), одинарные - нет. Если в shell-строке есть $ для самой оболочки, бери одинарные кавычки, иначе Groovy попытается подставить переменную раньше времени.
- agent none без agent в стейджах. Если на уровне pipeline стоит agent none, то каждый stage обязан объявить свой agent, иначе шагам негде выполняться.
- Один гигантский stage. Свалить checkout, сборку и тесты в один этап технически можно, но тогда Stage View бесполезен - не видно, где упало. Дроби на логические этапы.
Повтори руками, без этого не уложится:
- Создай в Jenkins новый Pipeline-проект. В поле определения выбери "Pipeline script" и вставь минимальный каркас с одним стейджем Build и шагом echo. Запусти, найди Stage View.
- Добавь второй и третий стейджи (Test, Deploy) с echo внутри. Перезапусти, убедись, что в Stage View стало три плитки.
- В одном из стейджей замени echo на sh 'date' и sh 'uname -a'. Открой Console Output, найди вывод команд.
- Сломай конвейер специально: убери блок steps вокруг шага. Прочитай сообщение об ошибке - так ты запомнишь, как выглядит нарушение иерархии.
- Перенеси этот скрипт в файл Jenkinsfile в корень git-репозитория и пересобери проект через "Pipeline script from SCM". Теперь твой конвейер - это код.
- Чем отличаются stage и steps и почему этапов должно быть несколько, а не один на всё?
- Что делает директива agent any и в каком случае каждому стейджу нужен свой agent?
- Какой шаг печатает строку в лог, а какой выполняет команду оболочки?
- Зачем нужен Stage View и как по нему быстро найти место падения сборки?
Конвейер Jenkins - это три уровня: agent отвечает где, stage отвечает какой этап, steps отвечает что делаем. Declarative-каркас pipeline -> stages -> stage -> steps в 2026 году стандарт, и его иерархию надо знать на автомате. Ты собрал первый рабочий jenkins pipeline с checkout, сборкой и тестами, научился читать Stage View и находить упавший этап. Дальше будем наращивать: переменные окружения, параметры, параллельные стейджи и агенты в Kubernetes. Но фундамент - вот эти node, stage и steps - останется тем же.
