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

Проверки запускаются для двух регионов и двух вариантов пакета. В интерфейсе GitLab видны четыре успешные job, но в собирающей job остался один result.txt. Все четыре артефакта содержали одинаковый путь out/result.txt. При скачивании архивов файлы попадали в одно место и перезаписывали друг друга.

Уникального имени архива artifacts.name недостаточно. Оно помогает человеку различать скачиваемые архивы, но не меняет пути файлов внутри. Для последующего объединения результат каждой комбинации должен жить в отдельном каталоге. Идентификаторы измерений матрицы удобно включить и в каталог, и в содержимое контрольного файла.

Полный пример с четырьмя результатами

Вместо реальной сборки pipeline создаёт по одному текстовому результату. Так легко проверить именно передачу файлов и их раскладку.

stages: [build, collect]

build-variant:
  stage: build
  image: alpine:3.22
  parallel:
    matrix:
      - REGION: [eu, us]
        FLAVOR: [small, full]
  script:
    - mkdir -p "out/$REGION/$FLAVOR"
    - printf '%s/%s\n' "$REGION" "$FLAVOR" > "out/$REGION/$FLAVOR/result.txt"
  artifacts:
    name: "$REGION-$FLAVOR"
    paths: [out/]

collect:
  stage: collect
  image: alpine:3.22
  needs:
    - job: build-variant
      artifacts: true
  script:
    - find out -name result.txt -type f -print
    - test "$(find out -name result.txt -type f | wc -l)" -eq 4

Собирающая job должна увидеть четыре пути: по одному для eu/small, eu/full, us/small и us/full. Порядок вывода find не закреплён, поэтому проверка не зависит от него. Число строк здесь корректно лишь потому, что имена каталогов заданы фиксированной безопасной матрицей и не содержат переводов строк.

needs, ссылающийся на параллельную job целиком, получает результаты её экземпляров. Если нужен только конкретный вариант, существует needs:parallel:matrix. Но сначала полезно наладить общий layout: выбор подмножества не исправит коллизии имён у тех вариантов, которые всё же скачиваются вместе.

Идентичные комбинации не создают разные работы

Имена экземпляров формируются из значений матрицы. Если повторить одинаковые значения в разных описаниях, можно получить совпадающие имена вместо ожидаемой дополнительной job. Перед ростом матрицы посчитайте реальные комбинации и посмотрите итоговые имена в редакторе pipeline.

Для длинных значений действуют ограничения длины имени job. Не помещайте в измерение полную строку параметров сборки только ради удобства. Используйте короткий стабильный идентификатор и отдельно сопоставляйте его конфигурации. Это также упрощает пути артефактов и сообщения об ошибках.

Матрица создаёт отдельные jobs, но фактическое одновременное исполнение ограничено доступными runner и их настройками. Четыре комбинации могут стоять в очереди, и это само по себе не означает ошибку parallel:matrix. Сначала проверьте количество созданных экземпляров, затем уже доступную ёмкость исполнения.

Для потребителя полезно хранить ожидаемый список комбинаций рядом с проверкой. Простое число четыре не заметит, что один вариант продублирован под другим путём, а нужный отсутствует. При росте матрицы сравнивайте именно набор идентификаторов и соответствие содержимого каждого результата его каталогу.

Проверка должна читать содержимое

В учебном примере достаточно четырёх файлов, чтобы поймать перезапись. Для релиза проверьте также, что файл каждого каталога соответствует именно этой комбинации. Иначе четыре файла могут существовать, но содержать один и тот же пакет из ошибочно переиспользованного cache.

Не передавайте результат сборки через общий cache матрицы без разделения ключей и понимания конкурентных записей. Artifacts связывают результат с конкретной job; cache предназначен для переиспользуемых зависимостей и имеет другой жизненный цикл. Сначала определите, что именно собирается, затем выбирайте канал и уникальные пути.

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

Ещё по теме

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

  • GitLab CI/CD: автоматизация сборки и деплоя ↗

    От первого .gitlab-ci.yml до pipeline, который тестирует код, собирает образ и выкладывает приложение. Runners, artifacts, cache, registry, окружения и безопасный откат — на одном практическом проекте.