[英]Gitlab Merge Request When To Approve
So we're having a little bit of a debate where I work as to what point should a reviewer "Approve" a Merge Request.因此,我们正在就审阅者应该“批准”合并请求的哪一点进行讨论。
We have setup some Gitlab Pipelines to run and carry out what I would say are fairly standard stuff (Build, Automated Tests, Sonar etc) .我们已经设置了一些 Gitlab 管道来运行和执行我所说的相当标准的东西(构建、自动化测试、声纳等) 。 Now we're trying to improve best practises across the department and a debate has started as to when the reviewer(s) should actually "Approve" the Merge Request.
现在,我们正在尝试改进整个部门的最佳实践,并且已经开始讨论审阅者应该何时真正“批准”合并请求。
We have the 1 argument that says the Pipeline acts as an "Approver" itself and if it fails it basically should prevent the Merge Request from happening, so it doesn't matter when the reviewer(s) hit that "Approve" button, because the reviewer(s) are reviewing the Code and not the pipeline.我们有 1 个参数表示管道本身充当“批准者”,如果它失败了,它基本上应该阻止合并请求的发生,因此审阅者何时点击“批准”按钮并不重要,因为审查者正在审查代码而不是管道。
And then you have another argument that says the reviewer(s) should not be "Approving" until the Pipeline passes, and they should be dependent on the Pipeline passing as to whether they should be "Approving" the Merge Request or not.然后你有另一个论点,说审阅者在管道通过之前不应该“批准”,并且他们应该依赖于管道传递来决定他们是否应该“批准”合并请求。
So should the reviewer(s) of a Merge Request wait until the the Gitlab Pipeline finishes and if the pipeline is successful then "Approve" or should they be able to "Approve" once they have reviewed the code, no matter if the pipeline has finished or not?因此,合并请求的审阅者是否应该等到 Gitlab 管道完成,如果管道成功则“批准”,或者他们应该能够在审阅代码后“批准”,无论管道是否有完成与否?
It's best practice to wait until the pipeline passes, review the code and then do an approval.最佳做法是等到管道通过,审查代码然后进行批准。 If the pipeline doesn't pass in the first place, there is an issue and the developer needs to fix his/her PR before someone spends time to review it.
如果管道一开始没有通过,那么就有问题了,开发人员需要在有人花时间审查之前修复他/她的 PR。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.