с памятью все ок на сервере, а просто так накидывать дженкинсу дополнительно xmx не хотелось бы

ого, нет, не сталкивались, правда мы на 2.289.1 ещё, но невелика разница
а там как, Unable to create new native thread? Скинь полный стектрейс

Да, именно

ava.lang.OutOfMemoryError: unable to create new native thread
 at java.lang.Thread.start0(Native Method)
 at java.lang.Thread.start(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor.addWorker(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
 at java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
 at com.google.common.util.concurrent.ForwardingExecutorService.submit(ForwardingExecutorService.java:105)
 at jenkins.util.InterceptingExecutorService.submit(InterceptingExecutorService.java:39)
 at com.google.common.util.concurrent.ForwardingExecutorService.submit(ForwardingExecutorService.java:105)
 at jenkins.util.InterceptingExecutorService.submit(InterceptingExecutorService.java:39)
 at hudson.remoting.DelegatingExecutorService.submit(DelegatingExecutorService.java:51)
 at hudson.remoting.InterceptingExecutorService.submit(InterceptingExecutorService.java:50)
 at hudson.remoting.InterceptingExecutorService.submit(InterceptingExecutorService.java:44)
 at org.jenkinsci.remoting.util.AnonymousClassWarnings.check(AnonymousClassWarnings.java:66)
 at org.jenkinsci.remoting.util.AnonymousClassWarnings$1.annotateClass(AnonymousClassWarnings.java:122)
 at java.io.ObjectOutputStream.writeNonProxyDesc(Unknown Source)
 at java.io.ObjectOutputStream.writeClassDesc(Unknown Source)
 at java.io.ObjectOutputStream.writeNonProxyDesc(Unknown Source)
 at java.io.ObjectOutputStream.writeClassDesc(Unknown Source)
 at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
 at java.io.ObjectOutputStream.writeObject0(Unknown Source)
 at java.io.ObjectOutputStream.writeObject(Unknown Source)
 at hudson.remoting.Command.writeTo(Command.java:111)
 at hudson.remoting.AbstractByteBufferCommandTransport.write(AbstractByteBufferCommandTransport.java:286)
 at hudson.remoting.Channel.send(Channel.java:766)
 at hudson.remoting.Request.callAsync(Request.java:238)
 at hudson.remoting.Channel.callAsync(Channel.java:1032)
 at hudson.remoting.PingThread.ping(PingThread.java:110)
 at hudson.remoting.PingThread.run(PingThread.java:90)
Caused: java.io.IOException
 at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:194)
 at hudson.remoting.PingThread.lambda$new$0(PingThread.java:72)
 at java.lang.Thread.dispatchUncaughtException(Unknown Source)

дженкинс не в докере случайно? У нас такое было, когда pids.max для cgroup'ы был превышен
Ещё у нас так было давно, тогда мы отключили UseCompressedOops (-XX:-UseCompressedOops в JAVA_OPTS прописали)

Не, не в докере, прямо на серваке крутится. Судя по диспетчеру он использует 300 MB, хотя для него выделено полтора гига. Буду крутить =/

а, это на винде?
попробуй ещё java melody plugin поставить, он "в моменте" может показать что с кучей, что с тредами

спасибо за совет!

Люди, подскажите пожалуйста, как сделать так, чтобы хэш коммита (который показывается в момент, когда дженкинс вытягивает новые изменения из репы) при нажатии вёл в репозиторий сразу? сейчас он не интерактивный почему то

приложил бы скрин, но тут нельзя

Выложи скрин на радикал фото

Добрый день! В ходе миграции проекта с SVN на Git выяснилось, что git плагин для Jenkins из коробки выполняет fetch команду(задача со свободной конфигурацией, без использования конвейеров), это означает что все изменения внесённые в локальную копию проекта на конечной станции, где выполняется сборка проекта и запуск тестов - просто игнорируются (различные контексты и настройки для тестов, которых в общем хранилище быть не должно). Неважно были ли выполнены на локальной копии команды git add и commit (без push естественно), при отрабатывании плагина эти изменения просто пропадают. Вместо fetch хотелось бы pull. Первый рабочий вариант - отказаться от использования плагина и через shell-скрипты использовать необходимые git команды. Второй вариант - у плагина имеется расширенный механизм merge before build, который позволяет мерджить различные ветки перед тем как выполнить build, но опять же там дополнительные "приседания", связанные с различными ветками. Ну и третий вариант использовать fetch как есть на заранее смердженной ветке. И всё бы хорошо, но есть перечень организационных сложностей. Возможно есть ещё какие-то варианты, о которых мне неизвестно? Буду признателен если поделитесь своим опытом.

все изменения внесённые в локальную копию проекта на конечной станции, где выполняется сборка проекта и запуск тестов

у вас вот тут ошибка. не надо так делать.

Ясно, спасибо, стало быть - дожимать организационные моменты :).

Всем доброго времени суток. Можно ли в пайплайне кодом повлиять на оценочное время для стадии?

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

Ошибку загуглить пробовал?

Целиком

Естественно

Добрый день, коллеги. После очередного обновления Jenkins, в настройках заданий все формы съехали в центр. Никто с этим не сталкивался? Как лечится?