Матрица 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, окружения и безопасный откат — на одном практическом проекте.
