问题描述
所以这个问题会有些含糊，我很抱歉，但我什至不知道从哪里开始.我们使用Jenkins在夜间自动化一些构建.我们使用Maven执行构建.有一阵子，一切都很好.我们有findbug，代码覆盖结果以及成功构建的稳定历史.突然之间，似乎是从现在开始，在运行单元测试时，我们得到了随机的NoClassDefFound异常.这非常奇怪，因为在此之前，日志消息清楚地显示了它正在构建源程序并成功.然后，单元测试开始运行，并且它们立即死于上述异常.我们最近确实对Jenkins进行了更新，但是我并不完全相信这与它有很大关系.真正奇怪的是，构建不会总是因此异常而失败.有时它们运行并通过良好，而其他时候它们立即失败.就特定的单元测试失败或找不到的特定类而言，失败是不一致的.尽管它们似乎围绕着相同的小型类和单元测试，但似乎没有任何实际的模式.
So this question is going to be somewhat vague, and I apologize, but I don't really even know where to start. We use Jenkins to automate some builds during the night. We execute our builds with maven. For a while, everything was working out nice. We had findbugs, and code coverage results and a steady history of successful builds. All of the sudden, seemingly out of now where we are getting random NoClassDefFound exceptions while the unit tests are being run. Its very strange, because before hand, the log messages clearly show it building the sources and succeeding. Then the unit tests start to run and they instantly die with the aforementioned exception. We did recently perform an update of Jenkins, but I'm not entirely convinced that has much to do with it. The really strange part is that the builds don't always fail with this exception. Sometimes they run and pass fine, other times they fail immediately. The failures are not consistent in terms of the specific unit tests that fail, or the specific classes which cannot be found. While they seem to revolve around the same small set of classes and unit tests, there doesn't appear to be any real pattern to it.
有没有其他人在jenkins上构建过maven?我真的不知道该怎么办.日志消息并不完全有用，我不知道该如何对Jenkins配置进行操作，以从失败的构建中获得更好的调试信息.如果有任何想法，我可以收集任何人可能需要的任何信息.这是来自最近失败的构建之一的示例堆栈跟踪:
Has anyone else out there seen this with maven builds on jenkins? I really have no idea what to do. The log messages aren't exactly useful, and I don't know what I could do to the Jenkins configuration to get better debugging information out of the failed builds. I can gather whatever information anyone may need if anyone has any ideas. Here is an example stack trace from one of the recently failed builds:
com.ipti.ptl.common.problems.detectors.CMDRProblemDetectorTest.afterPropertiesSetTest
Failing for the past 3 builds (Since Unstable#411 )
Took 18 ms.
Error Message
com/ipti/hardware/bcicinterface/CPacketReceivedArgs
Stacktrace
java.lang.NoClassDefFoundError: com/ipti/hardware/bcicinterface/CPacketReceivedArgs
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
at java.lang.Class.getDeclaredMethods(Class.java:1845)
at com.ipti.common.eventbus.EventBus.subscribe(EventBus.java:107)
at com.ipti.ptl.common.problems.detectors.CMDRProblemDetector.afterPropertiesSet(CMDRProblemDetector.java:23)
at com.ipti.ptl.common.problems.detectors.CMDRProblemDetectorTest.afterPropertiesSetTest(CMDRProblemDetectorTest.java:37
推荐答案
除了@jmkgreen所说的以外，或者如果您尝试这些步骤而又不能解决问题，我还将检查工件中的问题类路径. Surefire和JUnit不保证测试将按特定顺序运行.以不同的顺序运行测试可能会导致以不同的顺序加载类，并导致这些奇怪的问题. 此博客文章有一个非常好的解释.
In addition to what @jmkgreen says, or if you try those steps and they don't solve the problem, I'd check for a problem in the artifact's classpath. Surefire and JUnit don't guarantee that tests will run in a particular order. Running tests in a different order may cause classes to be loaded in a different order and result in these weird issues. This blog post has a really nice explanation.
如果这就是正在发生的情况，那么您可以采取一些步骤来清理工件的依赖项.
If that's what seems to be happening, here are some steps you can take to clean up the artifact's dependencies.
删除所有不需要的依赖项
确保每个依赖项仅包含一个版本(例如，仅一个Spring框架).
Ensure there is only one version of each dependency included (e.g. only one Spring framework).
特别注意组ID或工件ID已更改的工件.对于这些情况，Maven依赖关系解析过程无法检测到一个工件应覆盖另一个工件，并且包括这两个工件.这可能会引起有趣的，有时甚至是不确定的问题.一个示例是spring.jar与spring-core.jar.
Pay particular attention to artifacts where the group ID or artifact ID has changed. For these cases, the Maven dependency resolution process cannot detect that one artifact should override the other and includes both. This can cause interesting and sometimes non-deterministic problems. One example is spring.jar vs. spring-core.jar.
如果应用程序包含多个支持相同功能的依赖项，则您需要按照 Maven文档.
If the application includes more than one dependency supporting the same functionality, you'll need to manually exclude the unwanted dependencies as described in the Maven documentation.
确保相关的依赖项都使用相同的版本
例如，如果项目包含多个Spring工件(spring-core，spring-jdbc，spring-aop等)，请确保所有版本都相同.使用dependencyManagement或根据需要添加直接依赖项以使版本一致.
For example, if the project includes several Spring artifacts (spring-core, spring-jdbc, spring-aop etc.) make sure the version is the same for all of them. Use dependencyManagement or add direct dependencies as needed to make versions consistent.
将所有-all类型的依赖项替换为其组成部分
Replace any -all-type dependencies with their component parts
...，只有项目所需的内容. -all jars可能包含运行该库所需的每个类-重新打包到jar文件中，而Maven的依赖项解析过程无法获得它们-而不是将它们引用为依赖项.
... and only the ones needed by the project. -all jars may contain every class needed to run the library - repackaged into the jar file where Maven's dependency resolution process can't get at them - instead of referencing them as dependencies.
例如， mockito-all包含重新打包的Hamcrest版本，可能与项目想要的任何其他版本的Hamcrest 冲突使用(直到运行时才可能引起难以修复的问题！).
For example, mockito-all contains a repackaged version of Hamcrest, which could conflict with any other version of Hamcrest a project wants to use (and likely won't cause the hard-to-fix problems until runtime!).
这篇关于Jenkins上的随机构建失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！