Тесты в MR и master:
когда запускать дважды

Если текущий master — предок проверенного коммита MR, Git может передвинуть master на него. Без squash и rebase при слиянии новый коммит не появляется. [1]

Если master ушёл вперёд и ветки разошлись: обновить ветку MR, проверить новый результат, затем сливать. Сам Fast-forward не знает о тестах — обязательность CI задаётся отдельно.

from workers import WORKERS
from batches import BATCH_SIZE

def test_queue_fits():
    assert WORKERS * BATCH_SIZE <= 500

# Подставь SHA проверенного и влитого коммитов.
git diff --exit-code "$TESTED_SHA" "$MERGED_SHA" --

Для схемы «тесты кода только в MR» нужны все условия ниже. Это рабочая дисциплина для обычного процесса слияния, а не гарантия отсутствия ошибок в программе.

1. В master попадает проверенный коммит

   Settings → Merge requests: Fast-forward merge; squash — Do not allow; Enable automatic rebase prior to merge — выключено. После обновления ветки дождаться нового успешного CI. [1]

2. Успешные тесты обязательны

   Включить Pipelines must succeed; не считать skipped pipeline успешным. Обязательные тесты входят в MR pipeline, не исключены через rules и не имеют allow_failure: true. [4] [7]

3. Нет прямого пути в master

   Защитить ветку: Allowed to push and merge — No one; force push выключен. Право сливать MR задать отдельно через Allowed to merge. Проверить пересекающиеся правила доступа. [5]

4. Повтор действительно одинаковый

   Совпадают тесты, файлы, версии зависимостей, образ среды исполнения, параметры и значимое внешнее состояние. Фиксируй зависимости и образы по digest; одинаковый SHA не делает окружения одинаковыми.

Проверки с защищёнными переменными и отдельной релизной сборкой могут оставаться после merge. Доступ к таким переменным в MR зависит от защиты веток и настроек проекта. [6]

Примеры для Python. Выбери схему под свой процесс. Проверки релиза здесь обозначены отдельным скриптом проекта.

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
    - when: never

stages: [test, release_check]

default:
  image: python:3.12-slim

tests:
  stage: test
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    - python -m pip install --require-hashes -r requirements-ci.txt
    - python -m pytest -q
  allow_failure: false

release_check:
  stage: release_check
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
  script:
    - ./ci/verify-release.sh
  allow_failure: false

tests:
  stage: test
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
  script:
    - python -m pip install --require-hashes -r requirements-ci.txt
    - python -m pytest -q
  allow_failure: false

combined_tests:
  stage: test
  rules:
    - if: '$CI_MERGE_REQUEST_EVENT_TYPE == "merged_result" || $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"'
  script:
    - python -m pip install --require-hashes -r requirements-ci.txt
    - python -m pytest -q integration/
  allow_failure: false

Во всех примерах workflow разрешает только MR и push в основную ветку. Теги, расписания, API и ручной запуск отдельного branch pipeline не включены. Нужные события добавляй явно. Это также убирает лишний branch pipeline при push в ветку MR. [9]

Очередь нужна для совместимости параллельных MR. Merged results pipeline сам по себе не закрывает гонку двух слияний. При текстовом конфликте GitLab может запустить обычный MR pipeline вместо merged results — проверяй тип. [2] [3]

Free означает доступность функции, а не бесплатные вычисления: runners и лимиты CI считаются отдельно. Для Self-Managed важны и лицензия, и установленная версия. Auto-merge лишь ждёт обязательные проверки; сам по себе он не создаёт merge train. [4]