GitLab 14.0: разбираем breaking changes в YAML-пайплайнах и новые security scanning jobs

GitLab 14.0 вышел в конце июня, и по количеству breaking changes это самый серьёзный major за последнее время. Мы сопровождаем несколько клиентских инсталляций - и обновление пришлось делать не одновременно на всех, а поочерёдно, с паузами. Этот пост - про то, что реально сломалось и как мы это чинили, а не про то, что написано в release notes.

Что нового и почему это важно прямо сейчас

GitLab Marketing называет 14.0 «переходом к единой DevOps Platform» - в этом есть доля правды, но нас прежде всего интересовали конкретные изменения CI/CD, а не ребрендинг. Из существенного:

• Pipeline Editor стал значительно умнее: lint в реальном времени, визуализация DAG прямо в браузере, подсветка включаемых файлов через include. Работает без локального gitlab-ci-lint.
• Security dashboards доработали до состояния, когда ими реально можно пользоваться: сводный вид уязвимостей по группе проектов, фильтрация по severity, ссылки на конкретные jobs.
• DevOps adoption metrics - новая панель в Group > Settings > Analytics. Показывает по каждому проекту группы: есть ли пайплайн, используется ли SAST, Dependency Scanning, Code Coverage. Полезно когда проектов много и надо понять где «дыры» в покрытии.

Но до этих приятностей нужно сначала пережить breaking changes.

Что ломается при обновлении: YAML-синтаксис

Главная боль 14.0 - изменения в CI YAML, которые сделали несовместимой часть конструкций, работавших в 13.x.

only/except в сочетании с rules - ошибка конфигурации. В 13.x GitLab терпел смешение only/except и rules в одном job, выбирая один из механизмов. В 14.0 это явная ошибка: jobs:job-name config should not mix 'rules' with 'only'/'except'. Казалось бы, очевидно что надо было починить раньше - но у нас на одном проекте был шаблонный job из include, который использовал rules, а в конкретном .gitlab-ci.yml к нему добавляли only. Это работало. Теперь - нет.

Решение: привести всё к rules. Синтаксис only/except не удалён, но смешивать нельзя. Мы выбрали rules как основной - он гибче и поддерживает changes, exists, when: manual с условиями.

include:file без project теперь требует явного указания. В ряде конфигов у нас было include: /templates/job.yml - путь к файлу в том же репозитории. В 14.0 это работает, но поведение при использовании include:file внутри extends изменилось - несколько jobs начали игнорировать included-шаблоны без видимой ошибки в lint. Pipeline Editor сразу показал проблему, в отличие от CLI-lint который её пропустил.

artifacts:reports:cobertura переименован. Если использовали coverage reports через Cobertura XML, ключ изменился: cobertura -> coverage_report с вложенным coverage_format: cobertura. Старый ключ deprecated и в 14.0 генерирует предупреждение, но ещё работает - убрать до следующего major.

Удалённые переменные и ключевые слова. Несколько deprecated-с-12.x переменных и синтаксических конструкций окончательно удалены. Самое болезненное что мы встретили - CI_PROJECT_CONFIG_PATH переименована в CI_CONFIG_PATH ещё в 13.8, в 14.0 старая переменная не определена. В скриптах такое обычно не ловится при lint - только при реальном запуске.

Настройка security scanning jobs

GitLab предоставляет готовые шаблоны для SAST, Dependency Scanning, Container Scanning и Secret Detection. В 14.0 шаблоны обновились, и если раньше вы их включали через include:template, стоит перепроверить что они делают сейчас.

Базовая конфигурация для проекта с Python и Docker-образом:

include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml

variables:
  CS_IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  SAST_EXCLUDED_PATHS: "tests/, docs/"

Несколько практических наблюдений по настройке:

Container Scanning требует собранного образа. container_scanning job по умолчанию запускается в stage test и ожидает что образ уже в registry. Нужно явно указать зависимость от build-job или поставить stage после него. В шаблоне это не очевидно - job падает с pull access denied если образ ещё не опубликован.

SAST на mono-repo даёт много шума. Если в репозитории несколько языков, Semgrep (основной анализатор в GitLab SAST) запускается для каждого из них. Для большого репозитория с Python, JavaScript и Go это три параллельных job и несколько сотен findings при первом запуске, большинство из которых - false positives или известные issues. Имеет смысл сначала запустить с SAST_EXCLUDED_ANALYZERS для всего кроме одного языка, разобраться с результатами, потом добавлять остальные.

Secret Detection и история коммитов. По умолчанию Secret Detection сканирует только diff текущего MR. Если нужен полный scan истории - переменная SECRET_DETECTION_HISTORIC_SCAN: "true". На старых репозиториях это может занять заметное время и найти секреты в коммитах двухлетней давности. Что с ними делать - отдельный вопрос, но знать полезно.

Security dashboard работает только при наличии артефактов. Результаты сканирований попадают в dashboard только если job выполнился успешно и артефакт типа gl-sast-report.json (или аналогичный) загружен. Если job пропускается через rules - данных нет. В DevOps adoption metrics этот проект будет помечен как «SAST: No» - что технически неверно, но логично с точки зрения «у нас нет данных о результатах».

Порядок обновления

На практике мы делали так: сначала обновляли GitLab Runner до совместимой версии (Runner должен быть не старше версии GitLab или не более чем на одну major-версию новее), затем GitLab само. После обновления - Pipeline Editor на каждый .gitlab-ci.yml и смотрим на предупреждения. Только после этого - запуск пайплайнов.

На одном из проектов обнаружили что include:template в 14.0 начал тянуть обновлённые шаблоны, и SAST-job добавил новый анализатор которого раньше не было - и он падал из-за нехватки памяти на раннере. Пришлось ограничить через SAST_EXCLUDED_ANALYZERS.

Где сейчас

Три из пяти клиентских инсталляций уже на 14.0. Оставшиеся две - обновим на следующей неделе после согласования окна. Серьёзных инцидентов не было, но подготовительной работы с YAML-пайплайнами было больше чем ожидали. Pipeline Editor реально помогает - особенно визуализация includes, которую раньше приходилось держать в голове.

Security scanning настроен теперь на большинстве проектов где его раньше не было. DevOps adoption dashboard показал неожиданную картину: несколько проектов которые «конечно же с пайплайнами» - на деле имели только базовый build без каких-либо проверок. Это хорошая точка отсчёта для разговора с клиентом о том, что ещё можно улучшить.