Я столкнулся с этой проблемой примерно в то же время (апрель 2018 года) и обнаружил, что она запускается плагином Artifactory 2.15.0 (и позже). Больше года я оставлял этот плагин пониженным, чтобы избежать регистрации DEBUG в моих журналах сборки. Хотя это работало для меня (пока я не был вынужден обновиться на прошлой неделе из-за несовместимости с новыми версиями Artifactory), вполне возможно, что другой файл плагина или jar-файл в вашем classpath вызывает проблему в вашем случае.
Потратив целые выходные на устранение этой проблемы, я наконец нашел основную причину в моей среде сборки.
Важными моментами являются:
- Это проблема с путем к классу процесса сборки (например, Ant).
- Это не проблема конфигурации с Jenkins.
- Это нельзя исправить с помощью конфигурации проекта.
- Триггер (обновление Jenkins или плагина) не обязательно является основной причиной журналов DEBUG.
- При возникновении этой проблемы может быть несколько причин, из-за которых эту проблему очень трудно устранить.
Проблема бездействия
В моем случае основная причина ведения журнала DEBUG заключалась в том, что в моих тестовых зависимостях у меня было cobertura-2.1.1.jar , которое содержит файл logback.xml и также добавляет logback-classic.jar в качестве зависимости (широко расценивается как ошибка, см. Issue 2 , Issue 14 , Issue 36 ). Файл logback.xml , найденный в пути к классам, переопределяет любые другие параметры обратного входа в Jenkins (и создаваемый проект). Однако, поскольку 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 ). К вашему сведению, log4j 1.x использует корневой уровень ведения журнала по умолчанию DEBUG, а log4j 2.x использует глобальный уровень ведения журнала ERROR, который может быть совершенно другой источник журналирования отладки (но не в моем случае). Моя среда сборки (ant) поставляла log4j 2.10.0 и logback на classpath, что только мешало моему тестированию, приводя к противоречивым результатам в зависимости от того, какие плагины работали в процессе сборки.
При использовании плагина 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. Это огромная проблема, и, как вы можете видеть из вышеприведенных проблем с GitHub в Cobertura, хотя это и легко исправить, за четыре года не было предпринято никаких шагов по созданию фиксированной версии.
Исправление
Чтобы это исправить, мне пришлось сделать несколько изменений на моем сервере Jenkins:
Заменить logback-classic.jar и logback-core.jar на slf4j-simple-1.7.26.jar в моем * 1088Папка * .ant / lib (это путь к классу, который Ant использует при сборке и тестировании моих проектов).Это изменение вообще запрещает использование logback в Ant (поэтому любой файл logback.xml в classpath теряет свою актуальность), в то же время позволяя вашей сборке выполнять регистрацию через API SLF4J (через 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" /> <!-- IMPORTANT -->
</dependency>
Для справки, моя папка broken .ant / lib содержала эти файлы jar, связанные с журналированием (2 возможных источника DEBUGlogs):
- 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
в то время как my исправлено .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.Я велел logback «DEBUG All the Things!» , но никто не слушал, пока новая версия плагина Artifactory не изменила версию JCL и не принесла реализацию SLF4J, которая позволяла выбрать logback как «лучший доступный »каркас регистрации.Когда JCL был введен для logback, logback принял совет Cobertura и устроил вечеринку в моих журналах сборки.Этого можно избежать, удалив logback из среды и предоставив хорошо функционирующую инфраструктуру ведения журналов для JCL и SLF4J API (например, slf4j-simple ).