GIT_STRATEGY none оставил старые файлы: когда выбрать empty

Job развёртывания получает готовый архив из artifacts и не нуждается в исходниках. Чтобы не тратить время на Git, в ней включили GIT_STRATEGY: none. На постоянном runner появляется странность: команда находит файл, которого нет в текущем архиве. Путь остался от прежнего задания, а отключение Git одновременно убрало привычную подготовку рабочей копии.

Режим none означает пропустить Git-операции и использовать доступный рабочий каталог. Его нельзя читать как обещание пустой директории. Для задачи, которая должна начинаться с чистого каталога и затем получить cache или artifacts, у GitLab Runner есть стратегия empty. Выбор здесь связан с происхождением файлов, а не только со скоростью checkout.

Указать, какие данные нужны job

Допустим, build создаёт каталог dist, а inspect проверяет только его содержимое. Зависимость задаёт нужный artifact, empty убирает расчёт на оставшиеся исходники.

inspect:
  image: alpine:3.21
  variables:
    GIT_STRATEGY: empty
  needs:
    - job: build
      artifacts: true
  script:
    - test -d dist
    - find dist -maxdepth 2 -type f

Это фрагмент для pipeline с уже определённой build. Скрипт inspect не должен рассчитывать, что deploy.sh придёт из репозитория: checkout здесь отключён. Если нужен такой файл, включите его в явно передаваемый пакет или оставьте подходящую Git-стратегию. Иначе чистота каталога выявит настоящую скрытую зависимость, которую раньше случайно удовлетворяла старая рабочая копия.

Также проверьте cache. Пустой каталог до загрузки зависимостей не означает, что после восстановления cache он останется пустым. Если в cache попали результаты сборки, они снова добавят файлы. Разделите ускоряющие данные и обязательный вход задания: пакет релиза должен приходить по явной зависимости, а не по удачно совпавшему ключу cache.

Проверить последовательность двух запусков

На тестовом runner подготовьте первый pipeline, который создаёт уникальный маркер вне dist. Во втором pipeline уберите его создание и проверьте, что inspect не видит маркер. Такое наблюдение полезнее единственного чистого запуска: именно повторное использование каталога обнаруживает проблему. Для проверки временно добавьте test ! -e old-marker, не выводя содержимое всего окружения.

Посмотрите журнал подготовки job: какие Git-шаги пропущены, какие artifacts загружены и какой cache восстановлен. Если команда продолжает находить лишние файлы, теперь у вас есть короткий список источников. Это существенно удобнее, чем очищать неизвестный каталог rm -rf в начале каждого script.

Выбирать none тоже можно, когда повторное использование рабочего каталога намеренно и контролируется самим скриптом. Но такой контракт нужно описать явно. Для самостоятельного потребителя готового пакета empty обычно лучше выражает требование: вход определяется текущим pipeline, а не историей runner.

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

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

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

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

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