我们使用的是 SonarQube 5.5(最新的)。
我们的项目包含很多遗留代码，它们不会通过我们想要的 品质门 ，所以我们决定忽略已经存在的技术债务，但对新的变化要严格。
所以我们很享受Leak概念和默认的质量门，只考虑新的变化。
我们使用持续集成和持续交付，因此我们对每个 CI 构建运行 SonarQube 分析，以便能够向开发人员提供即时反馈，无论他们的更改是否未通过质量门，因此问题不会留到 sprint 结束，或者新的技术债务累积.
我们将泄漏期设置为 previous_version 因为我们每次运行都会增加版本号，但据我所知它可以设置为 previous_analysis 在我们的情况下具有相同的效果。
这种方法的问题在于，下一次好的提交将清除项目的状态(绿色、红色)，因为对最后一次提交的分析将通过质量门。虽然代码已经包含了之前提交中引入的问题。
如果 Leak Period 设置为固定日期\版本( 自定义日期 或 版本 选项)，将对累积提交运行分析，并且个别“坏”提交可能会被忽略，导致周期后期出现问题。所以它不满足“立即”的要求。
想象一下，在固定日期\版本之后，有 5 个相同大小的提交 - 4 个来自遵循 TDD 的“好”开发人员，因此覆盖率为 100%，而 1 个来自更改覆盖率为 0% 的“坏”人。平均而言，它会通过默认条件“新代码的覆盖率不低于 80%”，但实际上我们希望尽快向这些“坏”人提供反馈，以便他们改进他们的做法。
如果泄漏周期设置为滚动 分析前的天数 ，一旦自上次“错误”提交以来经过了这个天数，Gate 的状态就会清除，而问题可能仍然存在于代码中。
我们需要能够分析单个提交(类似于 SQ 中的“previous_version”泄漏期选项)。
但是如果最后一次提交通过了QG而前一次失败，我们应该一起分析它们，看看最后一次提交是否真的解决了前一次提交的问题，这样整个项目就可以被视为通过了。
所以，本质上我们应该分析自 以来的所有提交。上次成功分析
泄漏期没有这样的选项。
有没有其他方法可以实现这一目标？
最佳答案
要跟踪开发人员的代码覆盖率，您可以执行以下操作:
关于continuous-integration - SonarQube - 如何将最后一次成功的分析指定为泄漏期，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37145103/