GitLab CI: отменяем устаревшие сборки и сохраняем нужный деплой

Разработчик отправил три исправления за десять минут. Все три сборки одной ветки продолжают выполняться, хотя ревью нужен результат последнего commit. Отмена старых проверок экономит Runner, но та же политика для начавшегося деплоя может оставить окружение наполовину обновлённым.

Нужно разделить работы по допустимости прерывания. Сборка в отдельном временном каталоге обычно может начаться заново. Миграция данных или последовательность переключения релиза требует анализа побочных действий. GitLab позволяет выразить эту разницу через interruptible и политику auto_cancel.

Выберем понятный режим отмены

В режиме on_new_commit: interruptible новый commit отменяет jobs, отмеченные interruptible: true. У остальных работ политика иная. Следующий пример безопасно показывает различие с помощью ожидания, не выполняя настоящий deploy.

workflow:
  auto_cancel:
    on_new_commit: interruptible

stages: [build, deploy]

build_probe:
  stage: build
  image: alpine:3.21
  interruptible: true
  script:
    - printf '%s\n' "$CI_COMMIT_SHA"
    - sleep 90

deploy_probe:
  stage: deploy
  image: alpine:3.21
  interruptible: false
  resource_group: demo-environment
  script:
    - printf '%s\n' "$CI_COMMIT_SHA"
    - sleep 90

Запустите первый pipeline и отправьте новый commit, пока работает build_probe. Старая сборка должна отмениться, новая — начаться по обычным правилам. Затем повторите опыт, когда первый pipeline уже дошёл до deploy_probe: начавшаяся непрерываемая job должна продолжить выполнение. Сравнивайте SHA в журналах, чтобы не спутать два запуска.

Почему conservative даёт другой результат

У режима conservative отмена всего pipeline ограничена тем, началась ли уже job с interruptible: false. После её старта pipeline защищён от такой автоматической отмены, и оставшиеся проверочные jobs могут продолжить работу. Режим interruptible действует выборочно на отмеченные работы, поэтому его проще использовать, если нужно отменять тесты даже рядом с продолжающейся операцией.

Значение none отключает этот вид автоматической отмены. Кроме YAML проверьте настройку Auto-cancel redundant pipelines проекта и поддержку ключей версией сервера. Повторный ручной запуск того же commit не эквивалентен новому push: не используйте его как единственную проверку политики on_new_commit.

Interruptible не делает скрипт безопасным

До установки true посмотрите, что происходит при остановке в середине каждой команды. Если job загружает кандидат во внешнее хранилище, проверьте, не остаётся ли видимая недописанная версия. Если она только считает тесты, оставшийся временный каталог обычно не влияет на релиз. Разница определяется действиями скрипта, а не именем stage.

False защищает от выбранного механизма автоматической отмены, но не от ручной отмены, timeout, остановки Runner и сетевой ошибки. Реальный deploy всё равно должен уметь сообщить, на каком шаге остановился, и поддерживать повторный запуск или восстановление. В примере sleep только демонстрирует управление статусом.

Отмена и очередь решают разные вопросы

Resource_group ограничивает одновременное выполнение jobs с общим ключом в проекте. Он не определяет, какой commit считается актуальным. Даже если старые build отменены, непрерываемый deploy или ожидающая работа могут остаться в очереди. Проверьте процесс выбора jobs и политику устаревших релизов отдельно.

Особенно опасно считать, что последний push гарантированно будет последним выложенным результатом. Для деплоя нужны фиксированная версия объекта и проверка допустимости релиза перед изменением окружения. Автоматическая отмена уменьшает лишнюю вычислительную работу, но не заменяет управление версиями.

Как оценить результат настройки

Проведите два опыта с новым commit: во время сборки и во время начавшегося deploy_probe. Убедитесь, что отменяется именно разрешённая работа, а ожидаемые downstream jobs не запускаются после отменённого обязательного build. Затем посмотрите очередь Runner и время до результата последнего commit.

Эта тема отличается от устранения двойных pipelines на один push. Здесь несколько разных commits закономерно создают несколько запусков, а политика определяет судьбу устаревшей работы. После настройки команда должна уметь объяснить каждый продолжающийся job: он либо относится к актуальной проверке, либо завершает действие, которое нельзя безопасно оборвать.

Ещё по теме

• Cache и artifacts в GitLab CI: как передать результат сборки следующему job
• GitLab CI запускает два pipeline на один push: разбираем workflow и rules

Продолжить изучение

Хотите собрать проверяемый путь от коммита до релиза? Jobs, runners, артефакты и деплой — темы программы «GitLab CI/CD: автоматизация сборки и деплоя».