Окс, тут понял. Да вижу что ид юзера дженкинса другое.

root@ip:~# cat /etc/passwd | grep jenkins
jenkins:x:111:115:Jenkins,,,:/var/lib/jenkins:/bin/bash

Заменить стэп этот, на такой ?
args "-u 115:115 -v /jenkins/tools:/opt/tools:rw,z -v /jenkins/cache:/jenkins/cache:rw,z"

Как минимум, да

Но могут начаться проблемы внутри докера, т.к. в докере все собрано от рута и ид другой

🙂

Я по этому пути перешел, вижу что джарник созданный с правами рута. Так что выходит еще до cp происходит неверная логика.

/jenkins/cache/.m2/repository/com/Name/${MICROSERVICE}/${MICROSERVICE}/${pom.version}/${MICROSERVICE}-${pom.version}.jar

Сборка должна идти от переданного юзера по идее

Но тут точно не скажу, мы по-другому собираем. У нас свой образ сборки и запуска, внутри которого дергается мавен напрямую

Понял, спасибо. Буду смотреть

Всем привет, может кто-то сталкивался с такой проблемой при создании Allure отчета? Никак не могу найти решение проблемы(

слишком длинный путь, если я не ошибаюсь

Попробуйте перенести воркспейс в корень диска С. Проблема в слишком длинном пути на Винде

это приколы с докер агентом. Выставить uid аргументом -u не помогает, билд фейлится. Тут либо делать кастомный образ для агента с user ID таким же, как у Jenkins-а, либо вот такой уродливый костыль для стейджа:
       post {
         always {
           sh "chown -R 996:994 \$PWD"
         }
       }
post always после стейджа исполняется в докер-агенте, он завершит свою работу после выполнения. UID:GID свой подставьте.

Кстати, не наблюдал этой проблемы ни разу на кубере. И, кажется, если Jenkins тоже запущен в контейнере, этой проблемы тоже не было.

Плюсую, мы также костылем иногда делаем в итоге, я как раз примерно про такие проблемы говорил

я только их и юзаю

И дело в шляпе

Ну не смогло папку дропнуть - зачастую из-за того что гит или еще какая муть держит папку/файл. Особенно актуальная проблема для виндовых слейвов... Просто не стоит фейлить из-за этого весь билд

Уух, ну это жостко

Не совсем понимаю, как jenkins с помощью cleanws очистит воркспейс, в котором есть папки с правами root:root 740? Или этому плагину плевать на такие условности?))
Очищенный воркспейс слегка затрудняет дебаг, к тому же.

Я делал где-то условие, чтобы воркспейс чистился на второй раз подряд падающем билде.