Может с самим докером в образе werf связано? Тип как

проблема с docker-compose в нем?

А вы как его запускаете? В buildah-режиме в контейнере? Он там не будет работать, только kube-run

В гитлабе базовый образ верфа стоит как дефолтный. И в джобе просто werf run/werf compose. Gitlab раннер настроен по документации для docker engine. Для сборки использую stapel инструкции

kube-run используйте

Так это ж запуск прям в кубе. Нужно ли дёргать куб ради выполнения линтера. В кубе запуск же сложных интеграционных тестов. А простую команду и на раннере можно выполнить. Или так не надо?

В целом рекомендуется всё в кубах запускать. werf kube-run и был сделан для того, чтобы было просто запускать в кубе и простые вещи, вроде юнитов/линтеров и пр. Если хотите werf run, то придется использовать обычный docker-бекенд (в нашем образе через переменные окружения активирован buildah-бекенд).

А. То бишь для джобы переопределмть енв. Понял. А в целом, разве в таких случаях нагрузка на кластер - правильный подход? То бишь линтер, это же вроде часть ci системы, а мы получается его в нашем кластере выполняем

Мы его выполняем в контейнере, а где этот контейнер выполняется не так принципиально. Просто запускать все задачи, которые запускаются в собираемых werf'ом образах, там же в кубах, выглядело оптимальным решением — можем отвязаться от docker, кубы скейлить легче, чем раннеры, действительно идентичное окружение, ... (сейчас за давностью все причины не вспомню)

А не подскажите, какая переменная? Не смог найти в документации. Там про сам образ вообще не упоминается толком

Можно в контейнере env выполнить, там увидите. Сейчас скажу точно

Хм. Хорошо, подумаю над этим 😃

Можно в доку добавить раздел про образ. Какие у него настройки есть и что внутри)

https://github.com/werf/werf/blob/main/scripts/werf-in-image/alpine.Dockerfile#L18

Ага, благодарю

Там либо auto либо false получается?