Ответ
GitLab CI/CD запускается автоматически при наличии файла .gitlab-ci.yml в корне репозитория. Настройка сводится к правильному определению триггеров в этом файле.
Базовый пример: Пайплайн, который запускает сборку и тесты для каждого коммита в любую ветку.
# .gitlab-ci.yml
stages:
- build
- test
build-job:
stage: build
script:
- echo "Building the application..."
- mvn clean compile # Для Java Maven проекта
test-job:
stage: test
script:
- echo "Running tests..."
- mvn test
Контроль триггеров с помощью rules (предпочтительный современный способ):
Я использую rules для тонкой настройки условий запуска.
build-job:
stage: build
script:
- mvn clean compile
rules:
# Запускать для всех коммитов, кроме merge request
- if: $CI_PIPELINE_SOURCE == "push"
test-job:
stage: test
script:
- mvn test
rules:
# Запускать тесты всегда для main и develop веток
- if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop"
# Или запускать для merge request в main
- if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"
deploy-job:
stage: deploy
script:
- echo "Deploying to staging..."
rules:
# Запускать деплой ТОЛЬКО для коммитов в main ветку
- if: $CI_COMMIT_BRANCH == "main"
Использование changes для оптимизации:
Чтобы не запускать весь пайплайн при изменении, например, только документации, можно использовать правило changes.
backend-tests:
stage: test
script:
- cd backend && npm test
rules:
- changes:
- backend/**/*
- package-lock.json
frontend-tests:
stage: test
script:
- cd frontend && npm test
rules:
- changes:
- frontend/**/*
- package-lock.json
Ключевые переменные GitLab CI, которые я часто использую:
$CI_COMMIT_BRANCH: Имя ветки, для которой запущен пайплайн.$CI_MERGE_REQUEST_TARGET_BRANCH_NAME: Целевая ветка Merge Request.$CI_PIPELINE_SOURCE: Источник пайплайна (push,web,schedule,merge_request_event).$CI_COMMIT_TAG: Имя тега, если пайплайн запущен для тега.