Question

到目前为止，我们有一些作业构建，控制台输出显示许多奇怪的代码，如下所示，因此无法加载完整的日志，我们必须删除＆＃39; -X＆＃39;摆脱目标配置中的选项。我认为这是在我升级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]

Answer 1

大约在同一时间（2018年4月），我遇到了这个确切的问题，发现它是由Artifactory插件2.15.0（及更高版本）触发的。一年多来，我一直将该插件降级，以避免在构建日志中记录DEBUG。尽管这对我有用（直到上周由于与Artifactory的新版本不兼容而被迫升级），但您的类路径中的其他插件或jar文件很可能导致您的问题。

花了整个周末对这个问题进行故障排除后，我终于在构建环境中找到了根本原因。

要点是：

这是构建过程的类路径（例如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设置。但是，由于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，可能是DEBUG日志记录的完全不同的来源（但不是就我而言）。我的构建环境（ant）在类路径上提供了log4j 2.10.0和logback，这只能通过在构建过程中运行哪些插件产生不一致的结果来混淆我的测试。

使用Artifactory插件v2.15.0 +时，日志记录框架切换到logback，这将授予 cobertura-2.1.1.jar 中的 logback.xml 文件以将根日志级别设置为DEBUG，从而迫使构建过程的所有后续部分都以DEBUG级别进行记录。这包括 Apache Commons HttpClient 的有线日志记录，该日志记录会从每个HTTP /中生成 http-outgoing-0 （序列化的十六进制和交错的Base64编码内容）消息-如您在问题中所示）。即使对于小型项目，以这种方式记录一个JAR文件的单个PUT也会将构建时间和构建日志的大小增加几个数量级（这是我在构建环境中遇到的），这可以轻松削弱整个Jenkins服务器。这是一个很大的问题，从上面的Cobertura GitHub问题中可以看出，尽管这是一个简单的修复，但四年内没有采取任何步骤来生产固定版本。

修复

要解决此问题，我必须在Jenkins服务器上进行一些更改：

在 slf4j-simple-1.7.26.jar 中替换 logback-classic.jar 和 logback-core.jar 我的 .ant / lib 文件夹（这是Ant在构建和测试我的项目时使用的类路径）。此更改可防止在Ant中完全使用logback（因此，类路径中的任何 logback.xml 文件都不相关），同时仍允许您的构建通过SLF4J API执行日志记录（通过 slf4j -简单）。
删除对冗余日志记录版本的任何依赖关系（例如，不要在文件中同时包含 commons-logging-1.1.1 和 commons-logging-1.2 类路径）。如果使用log4j（版本1.1默认为DEBUG，版本1.2默认为ERROR），这尤其重要。您永远都不知道JCL将选择哪个基础框架，因此您想给它尽可能少的选择。

最后，为了使测试环境与Ant环境匹配，我将项目的 all 的依赖项调整为明确排除 登录-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>

作为参考，我的破碎 .ant / lib 文件夹包含以下与日志记录相关的jar文件（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

当我的 fixed .ant / lib 文件夹包含以下日志jar时：

commons-logging-1.2.jar （现在是唯一可用的JCL版本）
slf4j-api-1.7.26.jar （现在是唯一可用的日志记录框架）
slf4j-simple-1.7.26.jar （现在是唯一的SLF4J实现）

在我固定的Ant类路径中， commons-logging-1.2 只能选择SLF4J API（或JUL），并且只有一个SLF4J实现可用（ slf4j-simple >）。

TL; DR

三年来，Cobertura 2.1.1一直在告诉登录到“调试所有事情！” ，但是直到新版本的Artifactory插件更改了JCL版本并带来了一个SLF4J实现，它允许将登录选择为“最佳可用”登录框架。在将JCL引入logback时，logback采纳了Cobertura的建议，并在我的构建日志中加入了一个聚会。可以通过从环境中删除日志记录并为JCL和SLF4J API提供行为良好的日志记录框架（例如 slf4j-simple ）来防止这种情况。

Jenkins控制台输出充斥着http-outgoing

1 个答案: