Как директива `workflow` используется в файле .gitlab-ci.yml для управления CI/CD пайплайном?

«Как директива `workflow` используется в файле .gitlab-ci.yml для управления CI/CD пайплайном?» — вопрос из категории CI/CD, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Директива workflow: в GitLab CI/CD определяет глобальные правила, запускать ли пайплайн вообще. Она оценивается до создания любого задания (job) и действует на весь пайплайн.

Основное применение — условный запуск пайплайнов:

workflow:
  rules:
    # Запускать пайплайн ТОЛЬКО для main, тегов и merge request
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_COMMIT_TAG
    - if: $CI_MERGE_REQUEST_IID

    # НЕ запускать для веток с именем "wip/*"
    - if: $CI_COMMIT_BRANCH =~ /^wip//
      when: never

    # Для всех остальных случаев (ветки разработки) — запускать
    - when: always

Практические сценарии из опыта:

  1. Экономия ресурсов: Пропускать пайплайны для нерелевантных веток.

    workflow:
      rules:
        - if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop"
        - if: $CI_PIPELINE_SOURCE == "merge_request_event"
        - if: $CI_COMMIT_MESSAGE =~ /[skip ci]/i
          when: never
  2. Разные пайплайны для разных источников:

    workflow:
      rules:
        # Для merge request — полный пайплайн с тестами и сборкой
        - if: $CI_PIPELINE_SOURCE == "merge_request_event"
        # Для push в main — пайплайн с деплоем в прод
        - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push"
        # Для тегов — сборка и публикация релиза
        - if: $CI_COMMIT_TAG

Важно: workflow:rules оценивается сверху вниз. Первое совпавшее правило определяет судьбу пайплайна (when: always или when: never).