Checkstyle 和 Jenkins：检查 SVN 提交中修改/添加的行答案

【问题标题】：Checkstyle and Jenkins: check modified/added lines in SVN commitCheckstyle 和 Jenkins：检查 SVN 提交中修改/添加的行
【发布时间】：2013-02-08 02:32:38
【问题描述】：

我们有包含大量遗留代码的大型 Java 项目。现在我们有了代码约定和 Checkstyle 规则来检查它。

我们想要配置 Jenkins 作业，该作业在每次提交到 SVN 后运行，以检查修改/添加的行是否违反我们的任何 Checkstyle 规则。

由于遗留代码，无法检查整个项目。此外，我们不能只是重新格式化所有代码，因为这样就很难确定谁更改了特定的行以及更改的原因。

我们考虑的方法 - 区分以前和当前的 Checkstyle 报告，看看是否有新的违规行为。

问题是 - 我们如何在 Jenkins 中访问之前的 Checkstyle 报告？

或者如何将 checkstyle 配置为仅在有新违规时才构建失败？

对于此类检查是否有现成的解决方案？

【问题讨论】：

在类似的情况下，我们称为代码冻结，使用自动格式化程序重新格式化所有代码，并检查更改后的格式。现在我们可以通过与重新格式化之前的文件版本（对于非常旧的更改）或重新格式化之后的文件版本（对于较新的更改）进行比较来查看谁更改了什么。这对每个人都非常有效。

标签： java svn jenkins checkstyle

【解决方案1】：

这有点绕，但是如果您设置一个Sonar 实例来分析您的项目，您可以通过它的远程访问API 以编程方式查询违规数据。您知道遗留代码中的违规计数（大概这个数字不会经常更改）。这是您的基准 - 您不希望计数高于此值。

因此，在您的 CI 作业中，您可以在末尾添加一个脚本，调用 Sonar 以获取您关心的每个严重级别（拦截器、严重等）的违规计数，如果当前计数超过阈值/基准。

Sonar 总体上非常棒，特别是对于有大量遗留代码的项目，因为您可以深入研究并找出最危险的区域在哪里。如果您还没有检查过，他们会运行 public instance。

【讨论】：

【解决方案2】：

解决方案是制作一个 bash 脚本，与之前的 checkstyle 报告进行比较，如果有新的违规，则构建失败。

【讨论】：

【解决方案3】：

您是否查看了可用于 jenkins 的 Checkstyle Plugin？它将为每个提交生成报告，您可以比较每个更改的结果。每次提交都会触发一个新的构建，最后会生成一个新的报告。

【讨论】：

我当然检查过了，但问题是 - 我们如何才能访问以前版本的 Checkstyle 报告？
当插件本身会向您显示新的违规行为时，您为什么要进行比较？
您能告诉我，如何配置 checkstyle 插件以仅在出现新违规时无法构建？因为现在我们有很多它，并且无论是否有新的违规都构建失败。
通常在此类插件的高级配置中，您可以选择指定阈值。如果构建超过此阈值，您可以使构建失败或使其不稳定。如果您说构建失败而不管是否有新的违规行为，我想知道您是否设置了任何其他导致构建失败的属性。您在控制台输出中看到构建失败的原因是什么？
由于 checkstyle 违规导致构建失败：无法在项目 mms-interop 上执行目标 org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (default-cli): You有 1923 次 Checkstyle 违规。

【解决方案4】：

您是否检查过可用于 jenkins 的 Checkstyle 插件？它将为每次提交生成报告，您可以比较每次更改的结果。每次提交都会触发一个新的构建，最后会生成一个新的报告。Shiva Kumar

我当然检查过了，但问题是 - 我们如何才能访问以前版本的 Checkstyle 报告？

我也可以建议Static Code Analysis Plug-ins。这会将 Checkstyle 问题的趋势线显示为一个漂亮的图表。您也可以将其与 CI Game plugin 一起使用，这将为解决 Checkstyle 问题而奖励积分，并因引起更多 checkstyle 问题而扣分。

我发现 CI Game 插件运行良好 - 特别是如果您让您的开发人员参与一些竞赛：

我们将在本月的比赛中添加一些内容。众所周知，一等奖是一辆凯迪拉克 Eldorado。有人想看二等奖吗？（举起奖品）二等奖是一套牛排刀。三等奖是你被解雇了。

亚历克·鲍德温在格伦加里·格伦·罗斯饰演布莱克

当你把它变成一个有趣的游戏时，这些 Checkstyle 问题得到修复的速度真是令人惊讶。

【讨论】：

我知道这个插件，它们很好，但我们的主要目标是检查新提交的违规行为，而不是修复旧的违规行为。
Checkstyle 插件所做的只是解析 CheckStyle 任务生成的 XML 文件。无需在 Jenkins 中执行此操作，您需要在 build.xml 文件中修改 Checkstyle 任务。 CheckStyle ant 任务需要一个文件集，因此可以根据更改的文件构建一个文件集，然后仅在这些文件上运行您的 Checkstyle 任务。然后，詹金斯会做你想做的事。您也许可以使用Date。我得玩弄一下才能弄明白。如果我弄清楚了，我会附上我的答案。
顺便说一句，我们使用 Maven，而不是 ant。但问题是 - 如何持久化“CheckStyle 任务生成的结果 XML 文件”以供以后比较。
我不确定带有 Checkstyle 的 Maven 是如何工作的，但 Jenkins 中的 Checketyl 插件是 Jenkins 的 post-build 过程。 Jenkins 不运行 Checkstyle——您有责任确保您的项目生成 Checkstyle XML 文件。您所做的是在构建后过程中指定 1).您想要生成 Checkstyle 分析，以及 2)。您的构建生成的 Checkstyle XML 文件所在的位置。
我刚刚查找了 Maven 插件，这是 Maven 的领域之一……技术术语是什么？ ……哦，是的……糟透了。 Maven 是可以的，只要你顺从的直走窄就行。但是，如果你想做一些有点不同的事情，比如在有限的文件子集上运行 Checkstyle，你就有麻烦了。在这种情况下，我发现自己正在运行 Ant Maven 任务来做我需要做的事情。如果你还没有，看看 Jenkins Checkstyle 插件，看看它是如何工作的。