Pipeline изменился без коммита приложения: фиксируем версию include

В приложении ничего не меняли, но новый pipeline начал выполнять другие команды. Причина находится в общем CI-шаблоне: проект подключает файл из ветки main соседнего репозитория. Коллега обновил шаблон, и следующий запуск приложения получил его новую версию. Для общей автоматизации это удобно, но для воспроизводимого выпуска слишком много зависит от движущейся ссылки.

Include — часть кода процесса сборки. Если он определяет публикацию образа или деплой, его версия влияет на результат не меньше, чем Dockerfile. Поэтому полезно отделить разработку шаблона от принятия обновления каждым приложением. Полный SHA коммита позволяет указать конкретное состояние подключаемого проекта.

Привязать шаблон к версии

У include:project задайте проект, файл и ref с реальным полным идентификатором проверенного коммита. Схема выглядит так:

include:
  - project: platform/ci-templates
    ref: '0123456789abcdef0123456789abcdef01234567'
    file: '/templates/python.yml'

SHA в примере обозначает место для настоящего значения из вашего репозитория. Вставлять эту строку без замены нельзя. Прежде чем обновлять ref, посмотрите изменение шаблона и запустите тестовый pipeline. Тогда переход версии CI становится обычным review-изменением в приложении, а не неожиданным внешним событием.

Тег тоже может быть удобным договорным именем, если команда контролирует его неизменяемость. Но сама короткая запись v1 не объясняет, может ли кто-то передвинуть ссылку. Для критичного воспроизводимого выпуска полный SHA даёт более прямой ответ на вопрос, какой файл подключался. Человеческое имя версии можно оставить комментарием рядом.

Проверить всю цепочку подключений

Откройте итоговую конфигурацию pipeline и проверьте вложенные include. Зафиксированный внешний файл может сам подключать другой шаблон по подвижной ветке. В таком случае первый pin не замораживает всю цепочку. Аналогично версия общего YAML не фиксирует образ runner, пакеты из сети или результат команды curl; эти зависимости рассматриваются отдельно по их назначению.

Для проверки создайте новую ветку приложения с обновлённым ref и сравните состав jobs, команды, переменные и зависимости. Полезно проверять не только зелёный статус, но и нежелательные изменения: новый deploy, пропавшие тесты, расширившиеся условия запуска. CI Lint помогает увидеть структуру, а тестовый pipeline — исполнение в вашей среде.

После принятия обновления сохраните в истории приложения отдельный коммит с понятным сообщением. Если новая версия ломает сборку, возврат прежнего ref становится небольшим обзорным изменением. Общий шаблон продолжает развиваться для других команд, а конкретное приложение контролирует момент перехода и может объяснить, почему два его релиза собирались по разным правилам.

Продолжить практику

Исправление одной job полезно закрепить в полном процессе выпуска. В программе курса «GitLab CI/CD: автоматизация сборки и деплоя» — pipeline учебного приложения с проверками, тестами, сборкой Docker-образа, registry и staging. Отдельно разбираются runners, секреты, нестабильные запуски и возврат к предыдущему образу. Такой проект помогает увидеть, как решение внутри одной job влияет на выпуск версии и дальнейший откат.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Окружение задания и повторяемый pipeline.