Использовали ли вы директиву `rules` в GitLab CI/CD для управления выполнением заданий (jobs)?

Да, я широко использовал rules для создания гибких и эффективных пайплайнов в GitLab CI. Это замена устаревшим only/except с гораздо более мощной логикой.

Пример из реального пайплайна для микросервиса:

stages:
  - test
  - build
  - deploy

# Job 1: Запускать тесты всегда для MR и для мёржа в main, но не для тегов
unit-tests:
  stage: test
  script: ./run-tests.sh
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

# Job 2: Сборка Docker-образа только при пушe в main или вручную
build-image:
  stage: build
  script: docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: on_success # Автоматически после успешных тестов
    - if: $CI_PIPELINE_SOURCE == "web" # Ручной запуск из UI
      when: manual
      allow_failure: false

# Job 3: Деплой в staging только для main и только если изменилась папка deploy/
deploy-staging:
  stage: deploy
  script: ./deploy-to-staging.sh
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      changes:
        - deploy/**/*
        - Dockerfile
        - .gitlab-ci.yml
      when: on_success

Ключевые сценарии использования rules:

• Разные стратегии для веток и MR: Например, полный набор тестов для main, но только юнит-тесты для feature-веток.
• Условный запуск на основе изменённых файлов (changes:): Экономит ресурсы, запуская деплой только если изменились конфигурации или код приложения.
• Ручное подтверждение (when: manual): Для этапов деплоя на прод, требующих проверки.
• Комбинация условий: Использование && и || для сложной логики.

Важно помнить, что правила оцениваются сверху вниз, и первое совпавшее правило определяет судьбу job.