Ручной релиз не находит старые artifacts: срок хранения и неизменяемый релиз

В пятницу сборка прошла, а в следующий четверг оператор нажал ручной deploy. Job не смогла скачать artifacts. Повторная сборка того же commit выглядит быстрым выходом, но зависимости и инструменты могли измениться: получится новый результат, который прошлые тесты не проверяли. Сначала нужно понять, какой именно объект команда собиралась выпускать.

Artifacts удобны для передачи результата между jobs и хранения служебных отчётов. Их жизненный цикл связан с pipeline и настройками хранения. Для отложенного релиза нужна отдельная договорённость: точная версия объекта, целостность и доступность на весь срок согласования и отката.

Почему файл исчез не строго через expire_in

Посмотрите producer job и её artifacts:paths, срок expire_in, состояние загрузки и настройки хранения проекта. Если архив не был загружен изначально, увеличение срока ничего не восстановит. Если он удалён, повторная job-потребитель не воссоздаёт содержимое автоматически.

У сохранения последних artifacts на ref есть отдельные правила: они могут удерживать файлы независимо от expire_in. Поэтому наблюдение «старый файл пока доступен» не доказывает, что недельный срок настроен правильно. Новый pipeline, ручное удаление и изменение политики способны поменять доступность. Проверяйте фактическую настройку вашего сервера.

build_release:
  image: alpine:3.21
  script:
    - mkdir -p dist
    - printf '%s\n' "$CI_COMMIT_SHA" > dist/commit.txt
    - tar -czf release.tar.gz -C dist commit.txt
    - sha256sum release.tar.gz > release.tar.gz.sha256
  artifacts:
    paths:
      - release.tar.gz
      - release.tar.gz.sha256
    expire_in: 30 days

Учебный архив содержит SHA, чтобы было видно происхождение объекта. В реальном build замените его содержимое собранным приложением. Тридцать дней — пример выбранного срока, который должен покрывать ваши согласования. Этот YAML сам по себе не превращает artifacts в постоянное релизное хранилище.

Зафиксируем релизный объект

Для выпуска используйте версионируемый пакет или образ с идентификатором, который не переназначается. В Generic Package Registry путь содержит имя пакета, версию и файл. Удобно включать полный commit SHA и ID producer pipeline, а рядом сохранять checksum. Если проект разрешает повторную публикацию по тому же пути, настройте запрет дубликатов или проверку уникальности.

Имя вроде latest или ссылка на последний успешный artifact ветки не фиксирует один результат: следующий pipeline может изменить адресуемое содержимое. Для контейнера точную версию фиксирует digest образа. Человекочитаемый тег можно оставить рядом, но решение о деплое должно указывать проверяемый объект.

Проверим скачанный файл перед действием

В job ручного релиза сначала получите release.tar.gz и соответствующий release.tar.gz.sha256 из одной зафиксированной версии. Затем выполните локальную проверку целостности. Следующие команды работают с уже скачанными файлами и не разворачивают приложение.

sha256sum -c release.tar.gz.sha256
tar -tzf release.tar.gz

Первый шаг должен завершиться нулевым кодом и сообщением OK для архива. Второй показывает его состав. Несовпадение суммы означает остановку до изменения окружения. Контрольная сумма подтверждает совпадение с опубликованным манифестом; доверие к самому манифесту обеспечивается доступом к хранилищу и процессом публикации.

Если старый объект уже потерян

Не подменяйте его новым архивом под прежней версией. Создайте новый результат сборки с собственным идентификатором, повторите нужные проверки и согласуйте его как новый кандидат. Так история отражает, какие байты проверяли и какие в итоге выпустили.

Для процесса с долгими паузами полезен отдельный этап публикации кандидата: build формирует объект, тесты проверяют именно его, после успешных проверок версия становится доступна ручному релизу. Deploy получает готовую ссылку и checksum, а не решает заново, из какой ветки скачать последнее.

Проверьте сценарий задержки на тестовом релизе: дождитесь или смоделируйте недоступность временных artifacts, затем получите сохранённый пакет по точной версии. Если ручная job использует этот объект и проверяет сумму до деплоя, её работоспособность больше не зависит от случайного сохранения последней сборки ветки.

Ещё по теме

• Cache и artifacts в GitLab CI: как передать результат сборки следующему job
• GitLab CI не подключается к Docker daemon: DOCKER_HOST, TLS и executor

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

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