Через ран я же могу запустить только один образ и

запаралелить не могу?

Да, но можно распараллелить на уровне CI. В рамках сборки это прям не тру. Если вы уж хотите с этим велосипедом жить, то заверните образы в if eq .Env tests (https://werf.io/docs/v2/reference/werf_yaml_template_engine.html#env) и запускайте отдельно с --repo="". Если есть общие слои с остальными образами, то можно ещё --secondary-repo=$REPO прикрутить.

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

Отдельный werf-test.yaml

+ можете подробнее рассказать про промежуточные образы и ожидаемое поведение. Из вашего сообщения не понятно.

Если я правильно понял, то вы тесты можете переложить из image в artifact. Они не должны в final-repo отправляться (если ничего не путаю).

Ситуация. Есть много репозиториев 50+. В каждый репозиторий подключен сабмодуль, который содержит в себе универсальный хелм с базовыми знаниями, инструкция stapel для сборки базовых имеджей, набор темплейтов для стапела, а также единый werf yaml в котором собираются все необходимые кусочки. В каждом репозитории есть несколько директорий. src для исходного кода, values где лежит структура файлов для helm, build_vars где лежат файлы с параметрами сборки. Смысл заключается в том что разработчики могут положить в директорию build_vars файл с именем {service_name}.yaml где будут перечислены минимальные наборы параметров. Такие как на чем написан сервис dotnet(90%)/node/python и так далее, укажат путь к корню исходного кода в папке src (в этой папке код может быть сразу в корне для одного сервиса, может много директорий для разных сервисов), и указывают необходимо ли делать юнит тесты, проводить сканирование на уязвимости, сонар сканирование исходного кода и другие параметры. Исходя из этих параметров и логики заложенной в werf.yaml и stapel шаблоны система автоматически рендерит все необходимые шаги для выполнения. Так как большая часть кода это дотнет и все виды проверок чаще всего надо запускать после рестора пакетов, или вместе с Билдом(сонар) все эти шаги делаются внутри сборочного процесса. А так как сервисов иногда много (есть монорепы с 10+ сервисами) и они дробятся внутри одного репозитория, тратится много времени на отправку не нужных слоев в регистри(сонар, тесты, уязвимости). Раньше я тягал все это добро по всем регистри, потом использовал final-repo и теперь на прод не тянуться слои внутренних стейджов всех образов. Сейчас. Подключил параметр final: true final:false и теперь эти образа где проходят сканирования, не попадают в финальный регистри. Однако осталось проблема на pr пайпланах, мне надо запустить все (тесты, сонар, уязвимости) на кодовой базе которая мне достается из предыдущих слоев. Плюс надо запустить в правильном порядке и в правильной параллельности и передавать данные (файлы) между этим проверками. Например кое-где сонар должен запускаться после тестов чтобы забрать через импорт файл с покрытием, кое где сканирование на уязвимости должно запускаться после сонара, чтобы имело ссылку на сонар сканирование, чтобы передать эту информацию вместе со своими результатами на сервер. В итоге все работает и выполняется как надо, в правильном порядке и где необходимо, разработчики сами подкидывают файл для нового сервиса, и сразу же получают все необходимое. Но засчёт того что образов получается много, а некоторые вообще никак не нужны (только прогнать тесты) хотелось бы их скипнуть от загрузки в регистри, чтобы не тратить время на это. Надеюсь хоть что-то с моей писанины станет понятно))))

В werf version v2.9.1есть - If you simply need to limit the scope of image use, use the 'final' directive: ''' image: builder from: alpine:3.10 final: false ''' Вам подойдёт?

Добро. Тогда не понятно, почему вам не подходит один из предложенных мной вариантов (https://t.me/werf_ru/40539).

Про вот такой вариант, всё делается как надо, но все базовые образы не проверяются по хэшу в регистри, а начинают скачиватся. По итогу хотел избавиться от выгрузки образов, а получил загрузку

Если вы хотите базовые образы (или ещё какие-то слои) хранить в registry, то вы можете создать отдельные образы, на которых базировать свои тестовые (fromImage).