静态分析警告是否会使 CI 构建失败？
我们的团队正在研究项目中静态分析的各种选项，并且对于我们是否希望我们的持续集成构建因静态分析的警告而失败有不同的意见。
反对构建失败的论点是，规则中经常存在例外情况，而试图绕过这些例外只是为了使构建成功会降低生产力。更好的方法是在构建时生成报告，并定期投入开发人员时间来解决报告的问题。
反驳的观点是，如果不立即解决错误，技术债务很容易积累。此外，如果在引入潜在错误时构建失败，修复该错误所需的时间也会减少。
你有什么想法？
Our team is investigating various options for static analysis in our project, and have mixed opinions about whether we want our Continuous Integration build to fail because of warnings from static analysis.
The argument against failing the build is that there are often exceptions to the rules, and attempting to work around them just to make the build succeed reduces productivity. A better approach would be to generate reports with the build, and regularly dedicate developer time to addressing the reported issues.
The counter-argument is that it is easy for the technical debt to build up if the bugs are not addressed immediately. Also, if the build fails when a potential bug is introduced, the amount of time required to fix it is reduced.
What are your thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
就我个人而言，我宁愿看到构建失败。虽然某些警告是误报，但可以使用
Justification使用SuppressMessageAttribute来排除警告。执行此操作时，您可以确保开发人员会评估每个警告，并且不会漏掉任何内容。Personally I'd rather see the build fail. While some warnings are false positives, warnings can be excluded using a
SuppressMessageAttributeusing aJustification. When doing this, you are sure that every warning is evaluated by developers and nothing simply slips through.构建失败可能是个好主意，但这不一定是一个绝对黑白分明的决定。
Hudson 允许您在新静态分析错误达到某个阈值时让构建失败超过了。因此，您可以说“如果引入 1 个新故障，则将构建标记为不稳定；如果引入 5 个新故障，则将构建标记为失败”。
这是内置于 Hudson 可用的各种分析插件中的东西。
It's probably a good idea to fail the build, but this doesn't have to be an absolutely black and white decision.
Hudson lets you fail a build if a certain threshold of new static analysis faults is exceeded. So you can say "mark the build as unstable if 1 new fault is introduced; mark the build as failed if 5 new faults are introduced".
This is something that's built into the various analysis plugins available for Hudson.
我通常会因静态分析错误而导致构建失败（不仅是 CI 构建，还包括在提交之前在开发人员计算机上运行的构建，并且我使用可以包含在 IDE 中的工具）。
如果你不这样做，我的经验是错误不会得到修复，实际上永远不会，因为如果你认为错误是装饰性的（或者你不允许提交，对吧？），总会有更重要的事情去做。如果存在合理的例外，大多数工具都允许排除代码片段（使用自定义注释或排除过滤器等）。
如果您想使用静态分析，请正确执行，在问题发生时修复问题，不要让错误进一步传播到系统中。一个让这种情况发生的过程 是错误的：
I typically make the build fail on static analysis errors (not only the CI build but also the one that runs on developers machine before to commit and I use tools that can be included in the IDE).
If you don't do this, my experience is that errors don't get fixed and actually never will because if you consider errors as cosmetic (or you wouldn't allow the commit, right?), there will always be something more important to do. If there is a justified exception, most tools allow to exclude pieces of code (with things like a custom comment or an exclusion filter).
If you want to use static analysis, do it right, fix the problem when it occurs, don't let an error propagate further into the system. A process that lets this happen is wrong:
艰难的抉择，没有一个好的全球答案。我想同意之前的两篇文章，并说是的，但我的静态分析第二定律指出，缺陷将聚集在组织中软件工程过程最严重的部分。一个推论是，那些被迫匆忙更改代码以使警告消失的工程师，最有可能在这样做时引入新问题；我见过很多这样的错误，令人沮丧。我认为最好的软件工程是在代码外部进行误报标记，例如 Coverity 和 Klocwork，并基于此进行强制执行。
不言而喻，您关于尽可能大声地跟踪此类新缺陷并及时投入时间避免技术债务的主要观点是极好的想法。
Tough call, without a good global answer. I’d like to agree with the two previous postings and say yes, but my Second Law of Static Analysis says that defects will congregate in parts of the organization where the software engineering process is most badly broken. A corollary is that engineers who are forced to change their code in a hurry to make the warnings go away, are the ones most likely to introduce new problems when they do so; I’ve seen depressingly many such bugs. I think it’s better software engineering to do the false-positive marking outside the code, as in, e.g., Coverity and Klocwork, and do your enforcement based on that.
It goes without saying that your main point about tracking such new defects, as loudly as possible, and dedicating time promptly to avoiding technical debt, are excellent ideas.
除了因错误而失败之外，您还需要一个过程来调查警告，并决定其中一些警告是否应该成为错误。
In addition to failing on errors, you need a process to investigate the warnings, and to decide whether some of them should become errors.