GitLab не нашёл artifacts после cd: путь считается от каталога проекта

Команда сборки завершилась успешно и напечатала путь к отчёту, но Runner сообщает no matching files. В script перед сборкой выполняется cd build, а artifacts.paths содержит report.txt. Автор ожидает, что загрузчик продолжит работать из build. На самом деле пути артефактов задаются относительно каталога проекта, а не последнего cd в script.

Другая разновидность той же проблемы: инструмент пишет в /tmp/report.txt, а в artifacts.paths указан абсолютный путь. Сборщик артефактов рассчитан на файлы внутри checkout. Удобнее сразу направить результат в выделенную папку CI_PROJECT_DIR либо скопировать туда готовый отчёт перед завершением job.

Зададим один явный корень

Пример создаёт результат после cd, а в artifacts указывает путь от корня проекта. Он не требует реальной системы сборки и позволяет проверить только расположение файла.

build-report:
  image: alpine:3.22
  script:
    - mkdir -p "$CI_PROJECT_DIR/build/reports"
    - cd "$CI_PROJECT_DIR/build"
    - printf '%s\n' 'checks=4' 'failed=0' > reports/summary.txt
    - test -s "$CI_PROJECT_DIR/build/reports/summary.txt"
  artifacts:
    paths:
      - build/reports/summary.txt

После успешной job архив должен содержать build/reports/summary.txt. Проверка test использует полный путь, поэтому её смысл не зависит от текущего каталога. В YAML путь артефакта остаётся относительным: так видно, что именно будет собрано из рабочего дерева.

Если инструмент жёстко пишет в /tmp, после его успешного выполнения создайте папку в CI_PROJECT_DIR и скопируйте нужный файл туда. Затем проверьте размер или формат уже скопированного результата. Не расширяйте artifacts.paths на весь /tmp: там могут находиться чужие временные файлы и секретные данные.

Когда файл появляется позже script

after_script выполняется до загрузки артефактов, поэтому он может подготовить дополнительный диагностический файл. Однако его ошибки по умолчанию не равнозначны отказу основной команды. Если наличие отчёта обязательно для следующей job, создавайте и проверяйте его в script либо отдельной проверке с осмысленным статусом.

По умолчанию обычные artifacts загружаются для успешных jobs. Для диагностики неуспешного запуска можно задать when: always. Это не исправляет неправильный путь и не создаёт отсутствующий файл. Сначала убедитесь, что файл действительно сформирован к моменту upload, затем меняйте политику сохранения.

Если программа пишет результат постепенно и падает посередине, непустой файл ещё не доказывает полноту. Для отчёта с форматом проверьте штатный признак завершения или разберите документ. Условие test -s в учебном примере показывает расположение и наличие данных, но рабочая проверка должна соответствовать назначению результата.

Диагностика перед расширением масок

Добавьте в script вывод pwd и проверку конкретного полного пути. При необходимости покажите ограниченный список файлов каталога reports. Обычно этого достаточно, чтобы увидеть дополнительный уровень вложенности или ошибку имени. Полный рекурсивный листинг всего checkout создаёт шум и может раскрыть ненужные файлы.

Проверьте регистр имени: Summary.txt и summary.txt на Linux различаются. Также посмотрите, не переместила ли команда упаковки файл после создания. В логах должна быть последняя проверка того пути, который указан в artifacts, а не только сообщение инструмента о первоначальном выходном файле.

Когда артефакт появился в интерфейсе, скачайте его и проверьте внутренний путь. Следующая job получает именно это дерево файлов. Устранение ошибки upload завершено лишь тогда, когда потребитель может открыть ожидаемый результат без дополнительного угадывания каталогов.

В программе GitLab CI/CD есть artifacts, зависимости jobs и диагностика pipeline. Откройте программу и продолжите к сборке, где путь результата определён один раз и остаётся понятным от команды производителя до проверки и доставки.

Ещё по теме

• Матрица GitLab собрала четыре варианта, а файлов два: разделяем пути artifacts
• after_script не видит export и cd: передаём состояние файлом