Hello, A Merge Request in GitLab does not necessarily imply the need for a review by e person. It can just run a pipeline to validate that the code isn't broken. If the pipeline fails, the merge button is not available.
We use GitLab at work and we have it set up like this: * Main branches (develop/master/release/etc) are proteted and cannot be directly commited/pushed to, and only updated through MR * Each project defines what it's build/validate pipeline is (Jenkinsfile in project repo) * The pipeline is executed uppon creating the MR * if the Pipeline passes, the MR can be merged to the mainline branch This way we ensure that no code gets in that fails the build or with tests failing. P.S. We also store the build artifacts in a binary repository from where other pipelines can fetch them to be used in compiling other projects. P.P.S. This is the "DevOps" process used in most companies. The tools might differ, but the process is the same. It's the same for most FOSS projects as well. Regards, Ovidiu În ziua de joi, 28 martie 2019, la 10:29:22 EET, Kevin Ottens a scris: > Hello, > > On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote: > > Please note that the commits in this instance were pushed without > > review, so restrictions on merge requests wouldn't make a difference > > in this case unfortunately. > > Maybe it's about time to make reviews mandatory... I know it's unpopular in > KDE, and I advocated for "don't force a tool if you can get someone to look > at > your screen or pair with you" in the past. Clearly this compromise gets > somewhat exploited and that's especially bad in the case of a fragile and > central component like KDE PIM. > > Regards. >
signature.asc
Description: This is a digitally signed message part.
