Введение
В современной разработке программного обеспечения автоматизация играет ключевую роль. Она позволяет ускорить процессы сборки, тестирования и развертывания, минимизировать ошибки и повысить качество кода. Если вы используете Gitea для хостинга своих Git-репозиториев и Jenkins для автоматизации CI/CD, то интеграция этих инструментов станет мощным шагом к оптимизации вашего рабочего процесса.
В этой статье мы подробно разберём, как настроить интеграцию Gitea и Jenkins, чтобы автоматически запускать сборки и тесты при изменениях в определённых ветках. Даже если вы новичок, вы сможете легко разобраться в процессе и применить его в своих проектах.
Что такое Gitea и Jenkins?
Gitea — это легковесная и открытая система управления Git-репозиториями. Она позволяет хостить собственные репозитории, аналогично GitHub или GitLab, но с возможностью развертывания на собственном сервере. Gitea поддерживает все основные функции Git, включая ветвление, пул-реквесты, issues и вики.
Jenkins — это популярный инструмент для автоматизации процессов CI/CD (Continuous Integration/Continuous Deployment). Он позволяет автоматически собирать, тестировать и развертывать приложения при изменениях в коде. Jenkins поддерживает интеграцию с множеством инструментов, включая Gitea.
Зачем интегрировать Gitea и Jenkins?
Интеграция Gitea и Jenkins позволяет:
- Автоматически запускать сборки и тесты при изменениях в репозитории.
- Упростить процесс разработки, избавившись от ручных операций.
- Обеспечить высокое качество кода за счёт автоматического тестирования.
- Быстро развертывать приложения после успешной сборки.
Пошаговая инструкция по интеграции
1. Настройка Gitea
Перейдите в репозиторий Gitea.
Откройте Settings → Webhooks.
Добавьте новый вебхук:
Укажите URL вебхука Jenkins (например, http://<jenkins-server>/gitea-webhook/post).
Выберите события, которые будут отправлять уведомления (например, push или pull request).
2. Настройка Jenkins
Установите Jenkins и необходимые плагины:
Git Plugin (для работы с Git-репозиториями).
Gitea Plugin (для интеграции с Gitea).
Generic Webhook Trigger Plugin (опционально).
Создайте новый проект (Job) в Jenkins:
Выберите тип проекта, например, Pipeline.
Укажите URL вашего репозитория Gitea в разделе Source Code Management.
Настройте триггеры:
Включите GitHub/Gitea hook trigger for GITScm polling для автоматического запуска сборок.
3. Настройка Jenkins Pipeline для определённой ветки
Если вы хотите, чтобы Pipeline запускался только для определённой ветки (например, main), добавьте условие в Jenkinsfile:
pipeline {
agent any // Используем любой доступный агент
stages {
stage('Build') {
when {
branch 'main' // Указываем имя ветки
}
steps {
echo 'Building the main branch...'
sh 'mvn clean package' // Пример для Maven
}
}
stage('Test') {
when {
branch 'main'
}
steps {
echo 'Testing the main branch...'
sh 'mvn test'
}
}
}
post {
success {
echo 'Build and test completed successfully!'
}
failure {
echo 'Build or test failed!'
}
}
}
4. Расширенный Jenkinsfile для Spring проекта (сборка WAR, копирование по SSH, замена файла и перезапуск приложения)
Ниже приведён пример Jenkinsfile, который:
- Собирает Spring-проект в WAR-файл.
- Копирует WAR-файл на удалённый сервер по SSH.
- Заменяет старый файл на сервере новым.
- Перезапускает приложение через systemctl.
Для работы с SSH в Jenkins потребуется плагин Publish Over SSH. Убедитесь, что он установлен и настроен в Jenkins (в разделе Manage Jenkins → Configure System → Publish over SSH).
pipeline {
agent any // Используем любой доступный агент
environment {
// Переменные окружения
REMOTE_USER = 'deploy-user' // Пользователь для SSH
REMOTE_HOST = 'your-remote-server.com' // Удалённый сервер
REMOTE_DIR = '/var/lib/tomcat/webapps' // Директория для размещения WAR-файла
APP_NAME = 'myapp' // Имя приложения (без расширения .war)
SERVICE_NAME = 'tomcat' // Имя службы для перезапуска
}
stages {
// Этап сборки проекта
stage('Build') {
steps {
echo 'Building Spring project...'
sh 'mvn clean package' // Сборка проекта с помощью Maven
}
}
// Этап копирования WAR-файла на удалённый сервер
stage('Deploy') {
steps {
echo 'Deploying WAR file to remote server...'
sshPublisher(
publishers: [
sshPublisherDesc(
configName: 'my-ssh-server', // Имя SSH-конфигурации из Jenkins
transfers: [
sshTransfer(
sourceFiles: 'target/*.war', // Путь к собранному WAR-файлу
removePrefix: 'target', // Удаляем префикс (опционально)
remoteDirectory: REMOTE_DIR, // Удалённая директория
execCommand: """
echo 'Stopping service...'
sudo systemctl stop ${SERVICE_NAME}
echo 'Replacing WAR file...'
sudo rm -f ${REMOTE_DIR}/${APP_NAME}.war
sudo mv ${REMOTE_DIR}/*.war ${REMOTE_DIR}/${APP_NAME}.war
echo 'Starting service...'
sudo systemctl start ${SERVICE_NAME}
"""
)
]
)
]
)
}
}
}
post {
// Действия после успешной сборки
success {
echo 'Deployment completed successfully!'
}
// Действия при ошибке
failure {
echo 'Deployment failed!'
}
}
}
Пояснение к Jenkinsfile
Сборка проекта:
Используется команда mvn clean package для сборки Spring-проекта в WAR-файл.
WAR-файл создаётся в директории target/.
Копирование файла по SSH:
Плагин Publish Over SSH копирует WAR-файл на удалённый сервер.
Убедитесь, что в Jenkins настроен SSH-сервер (в разделе Manage Jenkins → Configure System → Publish over SSH).
Замена файла и перезапуск приложения:
На удалённом сервере выполняется команда для остановки службы (systemctl stop).
Старый WAR-файл удаляется, а новый перемещается в нужную директорию.
После этого служба перезапускается (systemctl start).
Переменные окружения:
Все настройки (имя сервера, пользователь, директория и т.д.) вынесены в переменные окружения для удобства.
Настройка SSH в Jenkins
Установите плагин Publish Over SSH.
Перейдите в Manage Jenkins → Configure System.
Найдите раздел Publish over SSH.
Добавьте новый SSH-сервер:
Укажите имя (например, my-ssh-server).
Введите хост, имя пользователя и пароль (или приватный ключ).
Проверьте подключение с помощью кнопки Test Configuration.
Что такое Jenkinsfile?
Jenkinsfile — это текстовый файл, который содержит определение Pipeline в Jenkins. Pipeline — это набор шагов, которые Jenkins выполняет для автоматизации процессов сборки, тестирования и развертывания приложений. Jenkinsfile описывает эти шаги в виде кода, что позволяет управлять процессом CI/CD (Continuous Integration/Continuous Deployment) как кодом (Infrastructure as Code).
Jenkinsfile обычно пишется на языке Groovy (или Declarative Pipeline syntax) и в нем могут содержаться:
- Этапы (stages): Например, сборка, тестирование, развертывание.
- Шаги (steps): Конкретные действия, такие как выполнение команд, вызов скриптов, копирование файлов и т.д.
- Агенты (agents): Где выполнять Pipeline (например, на конкретной ноде Jenkins).
- Триггеры (triggers): Условия для запуска Pipeline (например, вебхуки, изменения в репозитории).
- Переменные окружения (environment): Переменные, которые используются в Pipeline.
Jenkinsfile позволяет описывать весь процесс CI/CD в одном файле, что делает его удобным для управления и версионирования.
Где хранится Jenkinsfile?
Jenkinsfile обычно хранится в корне репозитория вашего проекта. Это позволяет Jenkins автоматически обнаруживать и использовать его при запуске сборки. Однако его можно хранить и в других местах, в зависимости от ваших потребностей.
1. В репозитории проекта (рекомендуемый способ)
Jenkinsfile находится в корне репозитория Git (или в другой папке, если указано явно).
Преимущества:
Версионирование: Jenkinsfile хранится вместе с кодом проекта.
Простота: Jenkins автоматически находит Jenkinsfile при сканировании репозитория.
Пример структуры репозитория:
my-project/
├── src/
├── pom.xml
├── Jenkinsfile
└── README.md
2. В Jenkins (вручную)
Jenkinsfile можно вручную ввести в интерфейсе Jenkins при создании Pipeline.
Преимущества:
Подходит для простых проектов или тестирования.
Недостатки:
Нет версионирования.
Сложно поддерживать и обновлять.
3. В удалённом хранилище (например, GitHub, GitLab, Gitea)
Jenkinsfile может находиться в другом репозитории или ветке.
Преимущества:
Можно использовать общий Jenkinsfile для нескольких проектов.
Недостатки:
Требуется дополнительная настройка в Jenkins.
Пример Jenkinsfile
Вот пример простого Jenkinsfile для сборки Java-проекта с использованием Maven:
pipeline {
agent any // Используем любой доступный агент
stages {
// Этап сборки
stage('Build') {
steps {
echo 'Building the project...'
sh 'mvn clean package' // Сборка проекта с помощью Maven
}
}
// Этап тестирования
stage('Test') {
steps {
echo 'Running tests...'
sh 'mvn test' // Запуск тестов
}
}
// Этап развертывания
stage('Deploy') {
steps {
echo 'Deploying the application...'
sh 'scp target/myapp.war user@server:/path/to/deploy' // Копирование WAR-файла на сервер
}
}
}
post {
// Действия после успешной сборки
success {
echo 'Pipeline completed successfully!'
}
// Действия при ошибке
failure {
echo 'Pipeline failed!'
}
}
}
Как Jenkins использует Jenkinsfile?
Обнаружение Jenkinsfile:
Jenkins сканирует репозиторий (или указанную папку) и ищет файл с именем Jenkinsfile.
Если Jenkinsfile найден, Jenkins использует его для запуска Pipeline.
Запуск Pipeline:
Jenkins выполняет шаги, описанные в Jenkinsfile, в соответствии с определёнными этапами (stages).
Логирование и отчётность:
Jenkins отображает прогресс выполнения Pipeline в интерфейсе.
Логи и результаты каждого этапа сохраняются для анализа.
Преимущества Jenkinsfile
Управление как кодом (Infrastructure as Code):
Jenkinsfile позволяет описывать процесс CI/CD в виде кода, что упрощает управление и версионирование.
Повторное использование:
Один Jenkinsfile можно использовать для нескольких проектов или веток.
Гибкость:
Jenkinsfile поддерживает как Declarative Pipeline (простой и структурированный синтаксис), так и Scripted Pipeline (более гибкий, но сложный синтаксис).
Интеграция с Git:
Jenkinsfile хранится в репозитории, что позволяет отслеживать изменения и управлять ими через Git.
Как Gitea взаимодействует с Jenkins?
Gitea может отправлять вебхуки (HTTP-запросы) на Jenkins при определённых событиях в репозитории (например, push, создание пул-реквеста). Jenkins, в свою очередь, может обрабатывать эти вебхуки и запускать сборки или другие задачи.
Основные способы интеграции Gitea и Jenkins:
Вебхуки (Webhooks):
Gitea может отправлять HTTP-запросы на Jenkins при событиях в репозитории (push, pull request и т.д.).
Jenkins может быть настроен на обработку этих запросов с помощью плагинов, таких как Generic Webhook Trigger Plugin или Gitea Plugin.
Ручная настройка Jenkins Job:
Jenkins может периодически опрашивать репозиторий Gitea (через Poll SCM) и запускать сборки при обнаружении изменений.
Использование API:
Jenkins может использовать API Gitea для получения информации о репозитории, коммитах, пул-реквестах и других данных.
Как настроить вебхук в Gitea для Jenkins?
В Gitea:
Перейдите в репозиторий.
Откройте Settings → Webhooks.
Добавьте новый вебхук:
Укажите URL Jenkins (например, http://<jenkins-server>/gitea-webhook/post).
Выберите события, которые будут отправлять уведомления (например, push, pull request).
В Jenkins:
Установите плагин Gitea Plugin (опционально, для более тесной интеграции).
Настройте Jenkins Job или Pipeline для обработки вебхуков:
Используйте GitHub/Gitea hook trigger for GITScm polling для автоматического запуска сборок.
Либо используйте Generic Webhook Trigger Plugin для более гибкой обработки данных из вебхука.
Пример настройки вебхука в Gitea
В Gitea:
URL вебхука: http://<jenkins-server>/gitea-webhook/post.
События: Push, Pull Request.
В Jenkins:
Создайте Pipeline и настройте его на обработку вебхуков:
pipeline {
agent any
triggers {
GenericTrigger(
genericVariables: [
[key: 'ref', value: '$.ref'], // Извлекаем имя ветки из JSON
[key: 'commit_hash', value: '$.after'] // Извлекаем хэш коммита
],
causeString: 'Triggered by Gitea webhook',
token: 'my-secret-token', // Опционально: для защиты вебхука
printContributedVariables: true, // Логировать переменные
printPostContent: true // Логировать тело запроса
)
}
stages {
stage('Build') {
steps {
echo "Building branch: ${ref}"
echo "Commit hash: ${commit_hash}"
sh 'mvn clean package'
}
}
}
}
Зачем нужен Generic Webhook Trigger Plugin?
Плагин Generic Webhook Trigger Plugin в Jenkins предоставляет гибкость для интеграции с внешними системами, которые могут отправлять HTTP-запросы (вебхуки). Он позволяет Jenkins реагировать на события из различных источников, таких как Git-репозитории (например, Gitea, GitHub, GitLab), системы управления задачами (Jira, Trello), или даже кастомные системы.
1. Универсальность
Плагин позволяет Jenkins принимать вебхуки от любых систем, которые могут отправлять HTTP-запросы. Это делает его универсальным инструментом для интеграции с разнообразными сервисами.
2. Гибкость
С помощью этого плагина можно:
Парсить данные из тела запроса (JSON, XML, текстовые данные).
Использовать эти данные в Jenkins Pipeline (например, для передачи параметров сборки).
Настраивать триггеры на основе конкретных условий (например, запускать сборку только при определённых событиях).
3. Интеграция с Gitea и другими Git-репозиториями
Хотя Gitea имеет встроенную поддержку вебхуков, Generic Webhook Trigger Plugin позволяет более гибко обрабатывать эти запросы. Например:
Запускать Pipeline только при определённых событиях (push в конкретную ветку, создание пул-реквеста и т.д.).
Извлекать данные из вебхука (например, имя ветки, хэш коммита) и использовать их в Pipeline.
4. Кастомные сценарии
Плагин полезен, если вы хотите:
Интегрировать Jenkins с системами, которые не имеют встроенной поддержки Jenkins (например, кастомные CI/CD системы).
Создавать сложные сценарии, где данные из вебхука влияют на логику Pipeline.
Как работает Generic Webhook Trigger Plugin?
Внешняя система отправляет вебхук:
Например, Gitea отправляет HTTP-запрос при push в репозиторий.
Запрос содержит данные в формате JSON (например, информация о коммите, ветке, пул-реквесте).
Jenkins принимает вебхук:
Плагин обрабатывает запрос и извлекает данные из тела запроса.
Эти данные можно использовать в Pipeline (например, как переменные окружения).
Запуск Pipeline:
На основе данных из вебхука можно настроить условия для запуска Pipeline.
Например, запускать сборку только для ветки main или только при создании пул-реквеста.
Пример использования Generic Webhook Trigger Plugin с Gitea
1. Настройка вебхука в Gitea
Перейдите в репозиторий Gitea.
Откройте Settings → Webhooks.
Добавьте новый вебхук:
Укажите URL Jenkins: http://<jenkins-server>/generic-webhook-trigger/invoke.
Выберите события, которые будут отправлять уведомления (например, push, pull request).
2. Настройка Jenkins Pipeline
В Jenkins Pipeline можно использовать данные из вебхука. Например:
pipeline {
agent any
triggers {
GenericTrigger(
genericVariables: [
[key: 'ref', value: '$.ref'], // Извлекаем имя ветки из JSON
[key: 'commit_hash', value: '$.after'] // Извлекаем хэш коммита
],
causeString: 'Triggered by Gitea webhook',
token: 'my-secret-token', // Опционально: для защиты вебхука
printContributedVariables: true, // Логировать переменные
printPostContent: true // Логировать тело запроса
)
}
stages {
stage('Build') {
steps {
echo "Building branch: ${ref}"
echo "Commit hash: ${commit_hash}"
sh 'mvn clean package'
}
}
}
}
Объяснение кода:
genericVariables: Извлекает данные из JSON-тела запроса. Например:
$.ref — имя ветки (например, refs/heads/main).
$.after — хэш последнего коммита.
causeString: Описание причины запуска Pipeline.
token: Опциональный токен для защиты вебхука (если требуется аутентификация).
Преимущества Generic Webhook Trigger Plugin
- Поддержка любых систем: Плагин работает с любыми системами, которые могут отправлять HTTP-запросы.
- Гибкая обработка данных: Можно извлекать и использовать любые данные из тела запроса.
- Упрощение интеграции: Не нужно писать кастомные скрипты для обработки вебхуков.
- Расширенные возможности: Поддержка фильтров, токенов и других функций для настройки триггеров.
Когда использовать Generic Webhook Trigger Plugin?
- Если вам нужно интегрировать Jenkins с системой, которая не имеет встроенной поддержки Jenkins.
- Если вы хотите использовать данные из вебхука для управления логикой Pipeline.
- Если вам нужна гибкость в настройке триггеров (например, запуск только при определённых условиях).
Заключение
С помощью Jenkins Pipeline и Gitea вы можете полностью автоматизировать процесс сборки, тестирования и развертывания ваших приложений.
Jenkins Pipeline — мощный инструмент для автоматизации CI/CD.
Publish Over SSH упрощает копирование файлов и выполнение команд на удалённых серверах.
Интеграция с Gitea позволяет автоматически запускать сборки при изменениях в репозитории.
Автоматизация развертывания экономит время и снижает риск ошибок.
Настройте Jenkins Pipeline для своих проектов и наслаждайтесь автоматизированным процессом разработки!
