lustre юзаете у себя?

использовали на одной из предыдущих работ

Всем привет, запускаю джобу на дженкинсе, и сталкиваюсь с такой ситуацией, все решения с гугла пробывал - не помогли, возможно кто то сталкивался? Юзаю TestNG

это ошибка не дженкинса

я понимаю что не дженкинса, но возможно кто то сталкивался

Версию явы проверь, такое бывает из за несоответствий версий

ок, спасибо

А мы сетапим приложение на обычный диск гугловый, потом его аттачим из RW в RO на ~70 нод, и внутри ноды монтируем через overlayfs чтобы получить RW. И потом запускаются тесты. Это оказалось быстрее всяких ceph или NFS.

Отказ от постоянно стореджа ))) и вообще нет проблем

именно. Нет стораджа - нет проблем :)

чет какая-то жесткая схема. Есть где-нибудь почитать подробнее о нюансах?

собственное ноу-хау :)
Задача прогонять много тестов в минимальное количество времени. Тестов реально очень много. На 4CPU ноде последовательно занимает почти 24 часа. Разработчик не будет ждать. Поэтому приходится параллелить. Но сетап приложения + все необходимые сервисы (PG, ES, RMQ, REDIS, Mongo и т.д.) Делается 1 раз на одной машине. Затем нужно все это размножить на инстансы где будут выполняться тесты.
Есть гугловый клауд который позволяет один обычный диск монтировать в RO режиме на много инстансов.  Поэтому делаем диск, аттачим RW на ноду где делаем сетап. На диске приложение и все данные для сервисов. Деаттачим и аттачим RO на все остальные инстансы. но нам нужно RW чтобы сервисы могли работать. Поэтому монтируем через overlayfs и диск используется как нижний слой. Запускаем сервисы и тесты.
Это оказалось наиболее быстрое решение. Ничего не копируется. Хорошо масштабируется. Тесты не зависят от сервисов и версии для конкретного случая можно выбирать и т.д.

мощно

Из того что пробовал раньше:
1. шаред сторадж.на гластере, ceph. Загибался на ~300 нодах.
2. просто копирование данных с ноды сетапа на другие ноды. Упиралось в сеть сетап ноды и копирование долго.
3. До этого когда тестов было мало и сервисов мало юзал stash/unstash tmp папку от overlayfs. Т.е. только изменения. Но все это тогда через мастер гоняется и быстро отказались от такого варианта т.к. нода мастера нужна оочень жирная.

а можно тебя/вас ещё потрясти на эту тему?)
Кейс — подпись файлов (условно, там упоротый процесс, но в первом приближении сводится к sign-file --in some.exe --out signed_some.exe --key secret.key), процесс долгий, файлов для подписи много, выполнять можно только на одной тачке в которую физически воткнут юсб-свисток необходимый для работы подписывалки
автопарк нод ограничен, задач разом может бежать много. Получается, что если делать что-то типа

node('builder') {
  sh 'build.py'
  stash 'unsigned' '*.exe'
  node('signer') {
    unstash 'unsigned'
    sh 'sign.py'
    stash 'signed' 'signed_*.exe'
  }
  unstash 'unsigned'
  sh 'package.py'

, то пока на ноде с signer будет полчаса бежать подпись файлов, нода с builder будет простаивать, хотя могла бы за это время разгрести ещё чего-нибудь ценного в очереди. Как быть, если задрать число экзекуторов или перейти к on-demand нодам пока не вариант? Мне пока что в голову приходит только нечто упоротое:

node('builder') {
  PREVIOUS_AGENT=env.NODE_NAME
  ...
}
node('signer') { ... }
node(PREVIOUS_AGENT) { ... }

, но я уже прям чую, что оно рассыпется нафиг, если до выполнения node(PREVIOUS_AGENT) на эту ноду упадёт следующий билд того же джоба и начнёт шариться в той же самой папке

вынести процесс подписи в отдельную джобу?

параллелить процесс подписи

а чем именно это поможет? разве что только весь процесс разбить на три джобы, тогда уж: отдельно билд, отдельно подпись, отдельно упаковка

т.е. разбить пайплайн на 3 джобы - до подписи, подпиь, после подписи