GitLab CI: `rules`, `workflow` и почему job не запустился

Один из самых неприятных вопросов в GitLab CI звучит не «почему job упал», а «почему job вообще не запустился?» В логе пусто, красной ошибки нет, а нужной проверки в merge request тоже нет.

Для новичков и мидлов это особенно сбивает с толку: кажется, что GitLab «сломался», хотя чаще всего сработали workflow: или rules:.

Коротко: кто решает, будет ли job

workflow:rules решает, создавать ли pipeline целиком. rules: у конкретного job решают, попадёт ли этот job в уже созданный pipeline. Если pipeline не создан, job не появится вообще. Если pipeline создан, но rule не совпал, job будет skipped или отсутствовать в зависимости от конфигурации.

Частые причины

1. workflow:rules отрезал весь pipeline. Например, конфиг разрешает только merge request events, а вы пушите в branch.

2. rules:changes не увидел нужных файлов. В monorepo это удобно, но легко забыть общий файл: lockfile, Dockerfile, shared package.

3. rules:if проверяет не ту переменную. CI_COMMIT_BRANCH и CI_MERGE_REQUEST_SOURCE_BRANCH_NAME живут в разных типах pipeline.

4. Schedule запускает другой сценарий. Scheduled pipeline часто не имеет MR-контекста, поэтому MR-only rules не совпадают.

5. when: manual выглядит как пропавший job. Он есть, но ждёт ручного запуска и может не блокировать MR.

Что смотреть в UI

• Страница pipeline: создан ли pipeline вообще.
• Вкладка pipeline editor / CI lint: как GitLab интерпретирует YAML.
• Тип pipeline: push, merge request, schedule, web.
• Переменные CI_PIPELINE_SOURCE, CI_COMMIT_BRANCH, CI_DEFAULT_BRANCH.
• Список skipped/manual jobs.

Мини-пример

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - when: never

test:
  script: npm test
  rules:
    - changes:
        - "packages/app/**"

Такой pipeline не создастся для обычного push, а job test не появится, если изменился только общий package-lock.json.

Когда job всё-таки упал

Если rules настроены правильно, следующий вопрос — почему job красный. Здесь уже важен лог. Exlogare подключается к GitLab CI и публикует RCA прямо в MR: автор видит не только статус, но и короткое объяснение причины. Настройка описана в GitLab CI ingest.

Читайте также

• GitLab Runner: docker, shell и kubernetes executor — три класса ошибок
• Статусы в GitLab, GitHub и Bitbucket: мини-словарь для DevOps

Чеклист

• Проверьте CI_PIPELINE_SOURCE.
• Разделите workflow:rules и job-level rules.
• Добавьте shared files в rules:changes.
• Проверьте MR pipeline отдельно от push pipeline.
• Не путайте skipped и manual.
• Для упавших job отправляйте лог в RCA, а не в чат скриншотом.