Вы доведёте красный конвейер Jenkins до зелёного: найдёте причину по журналу сборки, проверите Jenkinsfile на утечки секретов и пройдёте автоматическую проверку на живом контроллере. Падающий CI чаще чинят наугад, а здесь вы идёте от первой ошибки в консоли к её источнику. Ставить ничего не нужно: лабораторные запускаются в браузере на настоящем Jenkins с живым терминалом.
В job broken сборка падает на разборе файла: Jenkins ждал stage, а нашёл stge. Пока синтаксис не исправлен, до второго дефекта дело не доходит.
После правки сборка стартует и падает на пути к скрипту с кодом 127. Вы читаете журнал сверху вниз, чините ошибки по одной и после каждой пересобираете, пока последняя сборка на последнем коммите не станет зелёной.
Jenkins заменяет значение секрета на четыре звёздочки, и это ловит прямой вывод и base64. Но echo "$TOKEN" | rev печатает cba-t3rc3s, и секрет виден целиком.
Вы разбираете, какими каналами секрет всё же утекает: интерполяция в Groovy, трассировка set -x, артефакты и отчёты. Правите Jenkinsfile так, чтобы секрет жил в одном шаге, а печатали только факт, что он не пуст.
Git на уровне commit, branch и push.
Bash: запустить скрипт, прочитать вывод и код возврата.
Общее понимание, зачем нужен CI. Курсы по GitLab CI/CD и DevOps помогут, но не обязательны.
Три задания красные, и причина у каждого своя: не найдена версия библиотеки, неверный credentialsId или метка агента, которой нет ни у одного узла. Последняя сборка не падает, а ждёт бесконечно, поэтому красной не станет.
Для каждого класса есть своя проверка: git ls-remote --tags, список credentials по REST, метки узла. Лечить по аналогии нельзя: исправление метки не поможет заданию с опечаткой в credentialsId.
Правка идёт через git и JCasC, а не через ручное редактирование config.xml: ручная правка не попадает в историю и исчезнет при следующем применении конфигурации.
В итоговой работе вы собираете платформу из репозиториев: jenkins.yaml, jobs.groovy, библиотеку и приложение с Jenkinsfile. Повторное применение seed должно оставлять набор заданий прежним, пользователь dev запускает сборку, а guest получает 403.
DevOps и CI-инженерам, которые поддерживают Jenkins и хотят переходить от кликов к коду.
Backend-разработчикам, чьи сборки красные, а разобраться в консоли не получается.
Тем, кто готовится к собеседованию по CI и хочет показать разбор упавшего конвейера.
Лабораторная принимает работу, когда все три задания собраны зелёными. Проверка запускает сборки сама и смотрит на результат, а не на ваши слова.
Каждая лаба идёт на живом контроллере: Jenkins уже запущен, терминал открыт, вы правите репозитории и конфигурацию и нажимаете «Проверить».
Вы также можете задать любой вопрос по курсу у поддержки t.me/mentorix_support
Модулей: 8, уроков: 43. Задачи с кодом проверяются автоматически.
Стоимость курса: 6990 ₽