如何只分析新添加的代码行? [英] How to analyse only new added lines of code?
问题描述
我想在我的项目中使用 SonarQube.该项目相当大，扫描整个文件需要很长时间.是否可以仅扫描上次提交中更改的文件，并仅根据更改的代码行提供报告?我想检查添加或修改的行是否会使项目质量最差，并且我不关心旧代码.
I want to use SonarQube on my project. The project is quite a big and scanning whole files take much time. Is it possible to scan only changed files in the last commit, and provide report based only on changed lines of code? I want to check if added or modified lines make the project quality worst and I don't care about old code.
例如，如果 A 人创建了一个包含 9 个错误的文件，然后提交了更改 - 报告和质量门应该显示 9 个错误.然后人 B 编辑了同一个文件，添加了几行包含 2 个额外错误的行，然后提交了更改 - 报告应显示最后 2 个错误，并且应在最后更改时执行质量门(因此应考虑最后 2 个错误)
For example, if person A created a file with 9 bugs and then commited changes - the report and quality gate should show 9 bugs. Then person B edited the same file adding few lines containing 2 additional bugs, then commited changes - the report should show the 2 last bugs and quality gate should be executed on the last changes (so should consider the last 2 bugs)
我能够将扫描范围缩小到仅在上次提交中更改的文件，但报告是基于整个文件生成的.我有一个想法，只剪切更改的代码行，将它们粘贴到新文件并在文件上运行声纳扫描 - 但我几乎可以肯定 SonarQube 需要文件的整个上下文.
I was able to narrow scan to only changed files in the last commit- but report is generated based on whole files. I had an idea about cutting only changed lines of code, paste them to new file and run sonar scan on the file - but I'm almost sure the SonarQube needs the whole context of file.
是否有可能以某种方式实现我的用例?
Is it possible to somehow achieve my usecase ?
推荐答案
不，不可能.我看到很多类似的问题.以下是其中两个的答案:
No, it is impossible. I saw a lot of similar questions. These are answers to two of them:
G 安坎贝尔:
分析将始终包括所有代码.为什么?为什么要花时间仅更改一两个文件时分析所有内容?因为任何给定的变化都会产生深远的影响.我给你两个例子:
Analysis will always include all code. Why? Why take the time to analyze all of it when only a file or two has been changed? Because any given change can have far-reaching effects. I’ll give you two examples:
我签入了弃用常用方法的更改.突然，有关使用已弃用代码的问题应在整个过程中提出项目，但因为我只分析了一个文件，所以没有新问题提出来.
I check in a change that deprecates a much-used method. Suddenly, issues about the use of deprecated code should be raised all over the project, but because I only analyzed that one file, no new issues were raised.
我修改了一个经常使用的方法以在某些情况下返回 null.突然间所有不首先取消引用返回值的方法空检查它有 NullPointerExceptions 的风险.但只有分析了我更改的一个文件，因此没有一个可能的 NPE"提出的问题.更糟糕的是，他们直到每次之后才会被提升个别文件碰巧被触及.
I modify a much-used method to return null in some cases. Suddenly all the methods that dereference the returned value without first null-checking it are at risk of NullPointerExceptions. But only the one file that I changed was analyzed, so none of those "Possible NPE" issues are raised. Worse, they won’t be raised until after each individual file happens to be touched.
这就是为什么每次分析都包含所有文件的原因.
And that’s why all files are included in each analysis.
G 安坎贝尔:
首先，SonarQube 界面和默认的 Quality Gate 旨在帮助您集中注意力在新法典时期.你不能阻止分析捡起那些老问题，但您可以决定只关注提出的问题关于新更改的代码.这意味着您基本上会忽略项目主页左侧的issues带有白色背景并专注于黄色上的新代码值右边的背景.我们称之为修复泄漏，或者交替清洁代码.
First, the SonarQube interface and default Quality Gate are designed to help you focus on the New Code Period. You can’t keep analysis from picking up those old issues, but you can decide to only pay attention to issues raised on newly-changed code. That means you would essentially ignore the issues on the left side of the project homepage with a white background and focus instead on the New Code values over the yellow background on the right. We call this Fixing the Leak, or alternately Clean as You Code.
其次，如果你有商业版，那么分支和PR分析可供您使用.使用 Short-Lived Branch (SLB) 和 PR 分析仍然涵盖所有文件，但 UI 中报告的所有内容都是在 PR/SLB 中更改.
Second, if you have a commercial edition, then branch and PR analysis are available to you. With Short-Lived Branch (SLB) and PR analysis still covers all files, but all that’s reported in the UI is what’s changed in the PR / SLB.
理想情况下，您可以将这两者结合起来，以确保您的新代码保持干净.
Ideally, you’ll combine both of these things to make sure your new code stays clean.
在这件事上的立场在过去几年没有改变，所以不要指望它会改变.
The position in this matter has not changed over the last years, so don't expect it will be changed.
这篇关于如何只分析新添加的代码行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
