基本上，我使用Jenkins，Gitlab和Sonarqube进行了设置，但是我还没有对管道过程感到满意。一切都已集成，因此当开发人员将带有合并请求的功能将更改推送到功能分支时，针对该分支运行管道，这是qa步骤，如果qa不是绿色，则管道将失败。从理论上讲，到目前为止一切都很好。我正在使用Gitflow btw。
通常的方法是将所有feature / ，hotfix / 和release / *分支设置为短期分支，并开发和掌握长期分支。这很好用，但是我不喜欢将质量门硬编码到寿命短的分支上，我想使用我们的。开发人员花费在修复声纳上的问题的时间太高了。我确实想阻止MR，但配置文件要宽松一些。
因此，我已将所有分支机构切换为长期存在的分支机构。现在，我在所有分支中都定义了质量门，但是由于寿命短（现在很长）的分支在其生命周期中不会更改其版本，因此不会应用泄漏时间（因为它适用于以前版本中不存在的泄漏）短分支），因此永远无法真正衡量质量。合并请求不会被阻止，发布可以完成并进入主服务器，然后在主服务器上触发并开发的管道失败并拒绝将其部署到各自的环境时发生地狱。
tl; dr; 如何在没有硬编码的QualityProfile的情况下使用短暂的分支？或者，也许相反，我该如何将长期存在的分支与另一个分支作为基本版本进行比较，并得出泄漏时间？
谢谢您的建议。