Что сделать чтобы Jenkins мог видеть pull request, merge request и ветки в GitLab CI

Интеграция Jenkins с GitLab для видимости Pull/Merge Request и веток

Чтобы Jenkins мог "видеть" Pull/Merge Request (PR/MR) и ветки из GitLab, необходимо настроить двустороннюю интеграцию, которая позволяет Jenkins получать события из GitLab и анализировать состояние репозитория. Вот ключевые шаги:

1. Основные подходы к интеграции

Webhook-интеграция (рекомендуемый способ)

GitLab отправляет события (push, merge request) напрямую в Jenkins через HTTP-запросы.

Плагин GitLab Plugin для Jenkins

Стандартный плагин, который обеспечивает:

• Приём webhook-событий от GitLab.
• Отображение статусов сборки в GitLab.
• Автозапуск сборок для PR/MR.

Использование GitLab API

Jenkins может самостоятельно опрашивать GitLab через API для получения информации о ветках и MR. Часто комбинируется с webhook.

2. Подробная настройка через GitLab Plugin

Шаг 1: Установка и базовая конфигурация плагина

1. Установите плагины GitLab Plugin и Git plugin в Jenkins.
2. В Настройки Jenkins > Конфигурация системы найдите раздел GitLab.
3. Добавьте соединение с GitLab:

    *   Имя подключения (например, `gitlab-server`).
    *   URL GitLab (например, `https://gitlab.company.com`).
    *   Credentials: создайте токен доступа (Access Token) в GitLab (с правами `api`, `read_repository`) и добавьте его в Jenkins как секрет типа "Secret text".

Шаг 2: Настройка проекта (Job/Pipeline) Jenkins В конфигурации вашего Pipeline или Freestyle проекта:

// Jenkinsfile для Pipeline (Declarative Syntax)
pipeline {
    agent any
    triggers {
        gitlab(
            triggerOnPush: true,
            triggerOnMergeRequest: true,
            branchFilterType: 'All'
        )
    }
    stages {
        stage('Build') {
            steps {
                echo "Building branch: ${env.gitlabSourceBranch} for MR: ${env.gitlabMergeRequestId}"
                // Ваши шаги сборки
            }
        }
    }
}

Или в UI Freestyle проекта:

• В разделе Источник управления выберите Git, укажите URL репозитория и credentials.
• В Build Triggers отметьте "Build when a change is pushed to GitLab" и настройте фильтры веток.

Шаг 3: Настройка Webhook в GitLab

1. В вашем проекте GitLab перейдите в Settings > Webhooks.
2. URL вебхука: https://<jenkins-server>/project/<your-job-name> или многострочный триггер: https://<jenkins-server>/gitlab/build_now.
3. Секретный токен: сгенерируйте в настройках GitLab Plugin в Jenkins и скопируйте сюда.
4. Выберите события:

    *   **Push events** - для сборок при пуше в ветку.
    *   **Merge request events** - КЛЮЧЕВОЕ событие для видимости MR! Запускает сборку при создании/обновлении MR.
    *   При необходимости: Tag push events, Comments.

1. Добавьте webhook и протестируйте.

3. Работа с переменными окружения

При срабатывании триггера от GitLab, Jenkins получает набор переменных окружения, которые позволяют "видеть" контекст PR/MR:

# Пример переменных для Merge Request
echo "Исходная ветка MR: ${env.gitlabSourceBranch}"
echo "Целевая ветка MR: ${env.gitlabTargetBranch}"
echo "ID Merge Request: ${env.gitlabMergeRequestId}"
echo "URL Merge Request: ${env.gitlabMergeRequestUrl}"
echo "Тип события: ${env.gitlabActionType}" # push, merge_request и т.д.

Эти переменные можно использовать в скриптах для условной логики:

stage('Test') {
    steps {
        script {
            if (env.gitlabActionType == 'merge_request') {
                echo "Запущены тесты для MR #${env.gitlabMergeRequestId}"
                // Запуск специфичных для MR тестов (например, lint)
            } else if (env.gitlabActionType == 'push') {
                echo "Запуск полного набора тестов для ветки ${env.gitlabBranch}"
            }
        }
    }
}

4. Отображение статуса сборки в GitLab

Для полной интеграции важно отправлять статус сборки обратно в GitLab (значки в MR). Плагин делает это автоматически, если правильно настроены:

• GitLab connection в настройках проекта Jenkins.
• Токен доступа с правами api. В результате статус сборки появится в интерфейсе Merge Request.

5. Альтернативный метод: Опрос GitLab API

Если webhook недоступен, можно использовать триггер Poll SCM с дополнительными скриптами:

#!/bin/bash
# Пример скрипта для опроса открытых MR через GitLab API
MR_LIST=$(curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "https://gitlab.com/api/v4/projects/$PROJECT_ID/merge_requests?state=opened")

# Парсинг JSON и запуск сборок

Но этот метод менее эффективен и оперативен, чем webhook.

6. Ключевые проверки и устранение неполадок

• Доступность Jenkins из GitLab: Jenkins должен быть доступен по сети для GitLab (проблемы с NAT/Firewall).
• Совпадение секретного токена в webhook и в настройках плагина Jenkins.
• Правильные права токена в GitLab.
• Логи: Смотрите логи Jenkins (Журнал Jenkins) и GitLab (вкладка "Recent deliveries" у webhook).
• Используйте встроенную функцию Test для webhook в GitLab для диагностики.

Итог: Для полноценной видимости PR/MR и веток необходимо настроить связку GitLab Plugin + Webhook. Это обеспечивает автоматический запуск сборок при событиях и наполняет окружение Jenkins всеми необходимыми переменными о ветках и Merge Request, что позволяет писать гибкую и контекстно-зависимую логику пайплайна.