SonarQube 上的拉取请求分析和质量门

Question

我已经安装了 SonarQube 7.6 Developer Edition，并开始在我的开发环境管道中使用它。 我的编码方法是Trunk Based Development 。 我们只有一条主线（master 或 trunk 或您喜欢定义的开发，但只有一条主线）

实际上，所有代码更改都通过拉取请求，正如我所理解的，进入 SonarQube 被认为是一个短期分支，并且只应用了这个硬编码规则

错误条件：

• 新打开的错误 > 0
• 新的开放漏洞 > 0
• 新的开放代码异味 > 0

这是我的质量门条件的一个子集。 这意味着 PullRequest 可以通过质量门（因为被识别为短命分支）并且当它合并到主线（主/主干）时应用我的质量门规则并且可能在合并时失败。

我怎么知道它是否在 PR 批准之前打破了质量门，或者更简单，如何将拉取请求识别为长期存在的分支？

我试图将 * 定义为长期存在的分支模式，但它不起作用。 附上截图。

Answer 1

实际上，对于 SonarQube 7.6，这是状态：

• 所有 PR 都遵循 Short-Lived Branch 的相同规则，目前无法设置临时质量门（或至少与项目相同），但计划在 Q12019 进行。 更详细地说，PR 和 SLB 被认为是 2 种不同的东西，但它们在 SonarQube 中的表现是相同的。
• 无法将 PR 识别为长寿命分支（即使在长寿命分支模式正则表达式中使用 *）。
• 进入质量门的唯一方法是避免 PR 并在主线上启动合并，以检查质量门是否通过。

这里有来自 SonarQube 社区经理的回复

https://community.sonarsource.com/t/pull-request-analysis-and-quality-gate/6306/2