Консольный вывод Jenkins затоплен с http-исходящим

Question

Консольный вывод Jenkins затоплен с http-исходящим

Пока у нас есть некоторая сборка работы, вывод консоли показывает много странного кода, как показано ниже, поэтому мы не можем загрузить полный журнал, и мы должны удалить опцию -X в конфигурации цели сборки, чтобы избавиться от нее. Я думаю, что это произойдет после того, как я обновлю версию Jenkins. любая идея?

[DEBUG] http-outgoing-0 >> "j[0x5]q4/J[0x18]^di[0x86][0xbf]C_[0xd6]G[0x1d] 
[0xd4][0x7][0xf3][0xc7][0x14][0xdf][0x8d][0xe1][0x13][0xd8]$y|#[0x1e][0xbf] 
[0xe6][0x81]<[0xca][0x6][0xa1]~j[0x81]3[0xbc][0x98][0xd1][0x83][0xa7] 
[0xc5]8[0xfa]>[0xd9]edZ[0xb2][0xc][0xe0][0x5][0xab][0xf3][0x1a]M[0xb3][0xe7] 
[0x1][0xf4][\n]"
[DEBUG] http-outgoing-0 >> "[0xcd][0x9d][0x86]Zjp[0xb4][0x8d][0x87] 
[0x8f]cn[0xe7][0xab]oL.[0xb2]}[0x86][0xf8]D[0x87][0xba][0x9d][0xcc]j[0x15] 
[0xa4][0xe6]![0x9f]_BBC[0xbf]j[0xab]Rl[0x10][0x92][0xc5])[0xb2][0xc5]i[0xc2]

5

jenkins logging console continuous-integration verbosity

Источник

user6687534 15 май '18 в 04:00

2 ответа

Другие вопросы по тегам jenkins logging console continuous-integration verbosity

user2074605 18 июн '19 в 18:57 2019-06-18 18:57 · Answer 1 · 2019-06-18 18:57

Я столкнулся с этой проблемой примерно в то же время (апрель 2018 г.) и обнаружил, что она вызывается плагином Artifactory 2.15.0 (и более поздними версиями). Более года я оставлял этот плагин пониженной версией, чтобы избежать регистрации DEBUG в моих журналах сборки. Хотя это сработало для меня (пока я не был вынужден выполнить обновление на прошлой неделе из-за несовместимости с новыми версиями Artifactory), возможно, что другой плагин или файл jar в вашем пути к классам вызывает проблему в вашем случае.

Потратив целые выходные на устранение этой проблемы, я наконец нашел первопричину в своей среде сборки.

Важные моменты:

Это проблема с путем к классам процесса сборки (например, Ant).
Это не проблема конфигурации Jenkins.
Это не может быть исправлено через конфигурацию проекта.
Триггер (обновление Jenkins или плагина) не обязательно является основной причиной журналов DEBUG.
Когда эта проблема возникает, может быть несколько причин, что затрудняет устранение этой проблемы.

Дремлющая проблема

В моем случае основной причиной ведения журнала DEBUG было то, что в моих тестовых зависимостях был cobertura-2.1.1.jar, который содержит файл logback.xml, а также включает logback-classic.jar как зависимость (широко известную как ошибка, см. выпуск 2, выпуск 14, выпуск 36). Logback.xml файл, когда находится в пути к классам, отменяет любые другие настройки Logback в Дженкинс (и проект строится). Однако, поскольку логбэк не был фреймворком ведения журнала, выбранным Apache Commons Logging (JCL), этот параметр журнала никогда не запускался.

Триггер

При обновлении плагина Artifactory с 2.14.0 до 2.15.0 его ведение журнала изменилось с: commons-logging-1.1.1.jar (log4j-1.2.17.jar) на: jcl-over-slf4j-1.7.25.jar (slf4j-api-1.7.25.jar). FYI, log4j 1.x использует корневой уровень ведения журнала по умолчанию DEBUG, тогда как log4j 2.x использует глобальный уровень ведения журнала ERROR, который может быть совершенно другим источником ведения журнала DEBUG (но не в моем случае). Моя среда сборки (ant) поставляла log4j 2.10.0 и вход в систему по пути к классам, что только затрудняло мое тестирование, давая несогласованные результаты в зависимости от того, какие плагины работали в процессе сборки.

При использовании подключаемого модуля Artifactory v2.15.0+ фреймворк ведения журнала переключается в режим logback, который дает файлу logback.xml в cobertura-2.1.1.jar разрешение на установку корневого уровня журнала на DEBUG, заставляя все последующие части сборки процесс записи на уровне DEBUG. Это включает в себя ведение журнала для Apache Commons HttpClient, которое создает http-outgoing-0 (сериализованные шестнадцатеричные и чередование содержимого в кодировке Base64 из каждого сообщения HTTP/S - как вы показываете в своем вопросе). Даже для небольшого проекта запись одного PUT файла JAR таким образом увеличит как время сборки, так и размер ваших журналов сборки на несколько порядков (это то, что я испытал в своей среде сборки), что может легко вывести из строя весь ваш сервер Jenkins. Это огромная проблема, и, как вы можете видеть из проблем Cobertura GitHub выше, хотя это простое решение, не было предпринято никаких шагов для создания фиксированной версии за четыре года.

Исправление

Чтобы исправить это, мне пришлось внести несколько изменений на моем сервере Jenkins:

Замените logback-classic.jar и logback-core.jar на slf4j-simple-1.7.26.jar в моей папке.ant/lib (это путь к классам, который Ant использует при создании и тестировании моих проектов). Это изменение вообще предотвращает использование логбэка в Ant (поэтому любой файл logback.xml в пути к классам становится неактуальным), в то же время позволяя вашей сборке вести журнал через SLF4J API (через slf4j-simple).
Удалите все зависимости от избыточных версий журналирования (например, не включайте в путь к классам одновременно commons-logging-1.1.1 и commons-logging-1.2). Это особенно важно при использовании log4j, где версия 1.1 по умолчанию имеет значение DEBUG, а версия 1.2 - ERROR. Вы никогда не знаете, какой базовый фреймворк выберет JCL, поэтому вы хотите предоставить ему как можно меньше вариантов.
Наконец, для того, чтобы тестовая среда соответствовала среде Ant, я скорректировал зависимости всех моих проектов, чтобы исключить logback-classic (я использую Ivy для разрешения зависимостей, поэтому maven или gradle будут иметь другой синтаксис):
```
<dependency org="net.sourceforge.cobertura" name="cobertura" rev="latest.release" conf="test->default">
  <exclude org="org.apache.ant" />
  <exclude name="jaxen" />
  <exclude name="jetty" />
  <exclude name="jetty-util" />
  <exclude name="servlet-api-2.5" />
  <exclude name="logback-classic" /> 
</dependency>
```

Для справки, моя сломанная папка.ant/lib содержала эти файлы jar, связанные с журналированием (2 возможных источника журналов DEBUG):

commons-logging-1.1.1.jar (избыточная версия JCL, неизвестно, какая использовалась)
Commons-logging-1.2.jar
slf4j-api-1.7.21.jar (фреймворк для ведения журнала, используемый новым плагином для артефактов)
logback-classic-1.0.13.jar (фреймворк журналирования включен из cobertura-2.1.1)
logback-core-1.0.13.jar

в то время как моя фиксированная папка.ant/lib содержит следующие банки журналов:

commons-logging-1.2.jar (теперь единственная доступная версия JCL)
slf4j-api-1.7.26.jar (теперь единственная доступная структура ведения журналов)
slf4j-simple-1.7.26.jar (теперь единственная реализация SLF4J)

В моем фиксированном пути к классам Ant commons-logging-1.2 может выбирать только API SLF4J (или JUL), и доступна только одна реализация SLF4J (slf4j-simple).

TL;DR

В течение трех лет Cobertura 2.1.1 сообщала логбэк в "DEBUG All the Things!", но никто не слушал, пока новая версия подключаемого модуля Artifactory не изменила версию JCL и не принесла с собой реализацию SLF4J, которая позволила выбрать логбэк в качестве "наилучшей доступной" среды ведения журналов. Когда JCL был представлен для логбэка, логбэк последовал совету Кобертуры и устроил вечеринку в моих журналах сборки. Этого можно избежать, удалив логбэк из среды и предоставив хорошо работающую структуру ведения журналов для JCL и SLF4J API (например, slf4j-simple).

peterz 15 мар '23 в 13:15 2023-03-15 13:15 · Answer 2 · 2023-03-15 13:15

Итак, я недавно наткнулся на эту проблему, в моем случае это было вызвано установкой флага -X в maven на этапе сборки. Кто-то установил этот флаг и забыл его убрать. Это старая проблема, но, возможно, эта информация будет кому-то полезна.

0

Источник

peterz 15 мар '23 в 13:15