Открыть сервисСервис
Главная → Блог → Jenkins Plugin Development

Jenkins Plugin Development

Jenkins Plugin Development — это процесс создания программных расширений (плагинов) для системы непрерывной интеграции и доставки Jenkins, позволяющих расширять её функциональность, интегрировать с внешними сервисами, добавлять новые шаги сборки, типы узлов, источники кода, уведомления и элементы пользовательского интерфейса.

Общие сведения

Jenkins — это сервер автоматизации с открытым исходным кодом, написанный на Java. Его архитектура построена по модульному принципу: ядро Jenkins предоставляет базовую функциональность (управление заданиями, узлами, очередью), а вся дополнительная логика реализуется через плагины. Разработка плагинов позволяет адаптировать Jenkins под специфические нужды организации: от интеграции с внутренними системами управления конфигурациями до создания кастомных отчётов и панелей мониторинга.

Плагины для Jenkins распространяются через центральный репозиторий (Jenkins Update Center) или устанавливаются вручную. Они могут быть написаны на Java, Groovy (с использованием фреймворка Jenkins) или, в некоторых случаях, на других языках JVM.

История

Первая версия Jenkins (изначально Hudson) была выпущена в 2005 году. Уже в ранних версиях была заложена возможность расширения через плагины. С развитием экосистемы Jenkins количество доступных плагинов превысило 1800 (по состоянию на 2024 год). Разработка плагинов стала стандартной практикой для DevOps-инженеров и разработчиков, стремящихся автоматизировать специфические процессы.

В 2011 году после разногласий в сообществе проект был переименован в Jenkins, а Hudson остался как отдельный продукт. С этого момента развитие плагинов продолжилось под эгидой Jenkins, а сообщество разработчиков плагинов стало одним из самых активных в сфере CI/CD.

Архитектура и принципы

Модель расширений

Jenkins использует механизм расширений на основе аннотаций и интерфейсов. Основные классы и интерфейсы, которые наследуют плагины, находятся в библиотеке jenkins-core. Каждый плагин представляет собой Java-архив (JAR), содержащий классы, ресурсы и файл манифеста.

Жизненный цикл плагина

Плагин проходит через следующие стадии:

  1. Загрузка — Jenkins сканирует каталог plugins/ и загружает JAR-файлы.
  2. Инициализация — вызывается метод start() (если плагин реализует интерфейс Plugin).
  3. Работа — плагин участвует в выполнении заданий, обработке запросов, отображении UI.
  4. Остановка — при выключении Jenkins вызывается метод stop().

Типы расширений

Плагины могут реализовывать различные точки расширения (extension points). Основные из них:

  • Builder — добавляет шаг в сборку (например, выполнение скрипта, запуск тестов).
  • Publisher — выполняет действия после сборки (отправка уведомлений, публикация артефактов).
  • SCM — интеграция с системами управления версиями (Git, SVN, Mercurial).
  • Trigger — запуск сборки по событию (например, по расписанию или при изменении в репозитории).
  • Notifier — отправка уведомлений (email, Slack, Telegram).
  • Node — добавление нового типа узла (например, Docker-контейнер, облачная машина).
  • View — создание кастомного представления для списка заданий.
  • Action — добавление кнопок, ссылок или данных на страницу задания или сборки.

Инструменты разработки

Система сборки

Официально рекомендуется использовать Maven. Для создания плагина используется архетип (maven archetype) io.jenkins.tools.archetypes:jenkins-plugin-archetype. Он генерирует базовую структуру проекта с файлом pom.xml, содержащим зависимости от jenkins-core и plugin-util.

Среда разработки

Плагины разрабатываются в любой среде, поддерживающей Java и Maven (IntelliJ IDEA, Eclipse, VS Code). Для отладки используется запуск Jenkins с плагином в режиме mvn hpi:run, который запускает сервер Jenkins с установленным разрабатываемым плагином.

Тестирование

Для тестирования плагинов применяются:

  • JUnit — для модульных тестов.
  • Jenkins Test Harness — библиотека, эмулирующая окружение Jenkins для интеграционных тестов.
  • Jenkins Acceptance Test Harness (ATH) — для функциональных тестов через браузер.

Структура плагина

Типичный плагин содержит следующие файлы и директории:

`` my-plugin/ ├── pom.xml ├── src/ │ ├── main/ │ │ ├── java/ │ │ │ └── com/example/ │ │ │ ├── MyBuilder.java │ │ │ ├── MyPublisher.java │ │ │ └── ... │ │ ├── resources/ │ │ │ ├── index.jelly │ │ │ └── config.jelly │ │ └── webapp/ │ │ └── ... │ └── test/ │ └── java/ │ └── ... └── ... ``

  • pom.xml — файл сборки Maven, содержащий зависимости и плагины.
  • src/main/java/ — исходный код на Java.
  • src/main/resources/ — шаблоны представлений (Jelly, Groovy, HTML).
  • src/main/webapp/ — статические ресурсы (CSS, JS, изображения).

Пример: простой Builder

Ниже приведён упрощённый пример плагина, добавляющего шаг сборки, который выводит сообщение в лог.

```java package com.example;

import hudson.Launcher; import hudson.Extension; import hudson.util.FormValidation; import hudson.model.AbstractBuild; import hudson.model.BuildListener; import hudson.tasks.Builder; import org.kohsuke.stapler.DataBoundConstructor; import org.kohsuke.stapler.QueryParameter;

import java.io.IOException;

public class HelloWorldBuilder extends Builder {

private final String name;

@DataBoundConstructor public HelloWorldBuilder(String name) { this.name = name; }

public String getName() { return name; }

@Override public boolean perform(AbstractBuild build, Launcher launcher, BuildListener listener) { listener.getLogger().println("Hello, " + name + "!"); return true; }

@Extension public static class DescriptorImpl extends BuildDescriptor {

@Override public String getDisplayName() { return "Hello World Builder"; }

public FormValidation doCheckName(@QueryParameter String value) { if (value.isEmpty()) { return FormValidation.error("Name cannot be empty"); } return FormValidation.ok(); } } } ```

Развёртывание и публикация

Локальная установка

Собранный плагин (файл .hpi) помещается в каталог $JENKINS_HOME/plugins/. После перезапуска Jenkins плагин становится доступен.

Публикация в репозиторий

Для публикации в официальном репозитории Jenkins необходимо:

  1. Зарегистрироваться на сайте Jenkins.
  2. Создать репозиторий на GitHub (или другом хостинге) с открытым исходным кодом.
  3. Настроить CI (например, Jenkinsfile) для автоматической сборки и проверки.
  4. Подать заявку на включение в репозиторий через Jenkins JIRA.

После одобрения плагин становится доступен для установки через интерфейс Jenkins.

Особенности и ограничения

  • Версионная совместимость — плагины должны быть совместимы с версией Jenkins, на которой они запускаются. Рекомендуется указывать минимальную версию в pom.xml.
  • Безопасность — плагины выполняются в контексте Jenkins, поэтому необходимо избегать уязвимостей (инъекции, XSS, CSRF). Рекомендуется использовать встроенные механизмы Jenkins для экранирования и валидации.
  • Производительность — плагины не должны блокировать выполнение других заданий. Рекомендуется использовать асинхронные операции и пулы потоков.
  • Лицензирование — плагины обычно распространяются под лицензией MIT или Apache 2.0, но могут быть и проприетарными.

Применение

Разработка плагинов для Jenkins используется в следующих сценариях:

  • Интеграция с внутренними системами компании (баг-трекеры, хранилища артефактов, системы мониторинга).
  • Создание кастомных шагов сборки для специфических языков или фреймворков.
  • Реализация нестандартных уведомлений (например, через Telegram, Mattermost, Jira).
  • Автоматизация развёртывания в облачных средах (AWS, Azure, GCP).
  • Создание собственных панелей мониторинга и отчётов.

Источники

  • Jenkins Documentation — Plugin Development Guide
  • Jenkins Wiki — Extending Jenkins
  • Jenkins Plugin Tutorial — Jenkins CI Project
  • Jenkins JIRA — Plugin Submission Process
  • Официальная документация Jenkins по разработке плагинов (jenkins.io/doc/developer/)

Похожие материалы

Заметили ошибку или не согласны с информацией в статье? Напишите нам support@bfometr.ru