Какие бывают триггеры для запуска пайплайна сборки (CI/CD)?

В контексте CI/CD для тестирования, триггеры определяют, когда автоматически запускается пайплайн. В моей практике я настраивал и использовал следующие:

• Push в ветку репозитория: Самый распространенный триггер. Например, пайплайн запускается при любом пуше в main, develop или в feature-ветки по паттерну feature/*.
• Создание Pull Request (PR) / Merge Request (MR): Критически важный триггер для QA. Запускает пайплайн, который выполняет:
  • Сборку приложения.
  • Запуск модульных и интеграционных тестов.
  • Запуск статического анализа кода (линтеры, SonarQube).
  • Часто блокирует мерж, если тесты не проходят.
• По расписанию (Scheduled / Cron): Используется для регулярных задач, например:
  • Ночной прогон полного регрессионного тест-сьюта.
  • Запуск нагрузочных тестов в нерабочее время.
  • Обновление тестовых данных или окружения.
• Ручной запуск (Manual): Позволяет QA-инженеру вручную запустить пайплайн для конкретной ветки или с определенными параметрами (например, для запуска тестов на определенной среде).
• Запуск по завершению другого пайплайна (Pipeline Chaining): Например, пайплайн развертывания на staging-среде триггерит пайплайн запуска E2E-тестов.
• Webhook-вызовы: Внешние системы могут триггерить пайплайн через API. Например, система управления тест-кейсами (TestRail, Zephyr) может запускать пайплайн после обновления тест-плана.

Пример конфигурации триггера для GitLab CI (gitlab-ci.yml):

test:
  stage: test
  script:
    - echo "Running automated tests..."
    - npm run test:e2e
  # Триггер: запускать только при мерж-реквесте в ветку main
  only:
    - merge_requests
    refs:
      - main

Правильная настройка триггеров — ключ к эффективному процессу непрерывной интеграции и доставки.