GitLab Verify Group, 18 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How to avoid broken master with Merge Train

Description

How to avoid broken master with Merge Train

A

Hi everyone today I'd like to introduce you a brand new feature match train, which was released in gillip 12.1. This feature is incredibly useful when it comes to prevent master from being broken state. So the problem here is that sometimes much request is marched into the master branch. This module request had their successful pipeline and so maintainer did March the module request, but it turned out the pipeline runs on master branch after the March didn't pass some tests so that master branch is marked as broken state which gets failed to pipelines.

A

So here seeing this sample project. This is a very basic Roble. Rayless project and I have already added a pipeline here and you love SIA llamó file. The disk by blinding has one job, this test job and it executes Robocop command. This is a link check tool and it checks if there any cutting off hands at the source code. Now let me demonstrate how master branch can be broken at first.

A

Let's say: I'm developed for one and I'm going to change one of the Lynch rules, which is defined here.

A

Here's a one of the rules and I'm going to enable this. This doesn't allow empty method to be defined in source code and I'm, going to create a new, much request.

A

Ok seems good and now we're back to project page and now I am developer number two and this developer is going to add a new method and this method actually doesn't have any content. So it's violates the lint roll which just introduced by Marcus one.

A

Let's see we're going to this file and the let's edit.

A

Now we added dispersed mossad, but it doesn't have content, so it clearly violates a little introduced, a mushrik as one, let's create a module request.

A

Okay, now open to much requests. Here's a much request, one and here's Marcus.

A

Okay, now, let's get back to project page and this time, let's pretend pretend like maintainer of this project. Your responsibility is to marsh much requests into master branch, wizard breaking master branch, and now you are seeing Marcus Marcus one in a Marcus which is good because both smush request has successful pipeline.

A

Yes, so do you would think that maybe it's time to hit this Marsh button in both must request. So, let's try Marsh.

A

Okay, now both markets emerged: let's see master branch, here's a common history of master branch, and now we are seeing that- and this comment is made by marching dispatch request much biggest one and it has a successful pipeline.

A

On the other hand, the as I can't much commit, which was created by this Marsh come much request, has a failed pipeline. This is big house. Let's see the job log see, it seems the change introduced by Marcus to violate one of the lint rules. So the test didn't pass on master branch, so I've reported it both much requests and brought back a stable master again, and in this time we are going to use my strain to prevent master from being broken state, and let me briefly explain how my stream works.

A

So my strain is basically queuing system that you can add multiple match requests into the train and each match request generates expected Marsh commits and runs pipeline on it.

A

So, in this case, much request to is going to create a much comment as if much weakest, one has been merged into master branch and then module occurs should have a failed pipeline.

A

So, let's start the demonstration with mud strain. All you need to do is going here, setting general and much requests and as much options you see much pipelines. We try to validate the post match, result prior to merging and enable this checkbox and save the change and everything is set and let's create too much requests. It has exactly the same content with previous attempt.

A

Ok, now we have too much requests again. This is Marcus one which in turn, which changes one of the lead roles, and this is Marcus 2, which, as empty method, which violates the much which violates a lint rule, which was added by Marcus one and what's the difference from the previous attempt, it said now we are seeing this start mud stream button and we are going to add these two much requests into one stream.

A

Now we are saying that this much focused at the podium 1 and the new pipeline is created for maximum mass train and here's a market, and this much work is to also get our God on the match, train and created this pipeline. For mastering and as you can see, this Marcus one has been successfully merged into master branch. The pipeline has passed and then post pipeline shows that master is not broken, whereas this Marcus 2 shows that pipeline much train failed.

A

Let's see the reason. Yes, this is exactly same reason, which we saw.

A

This pipeline are much train failed because it violated one of the Lynch rules and this much requests was automatically removed from the mass rain and now yes, we successfully prevented mass or from being broken by Marcus, maybe later on. A developer is going to revisit this much focused and going to fix this.

A

This cutting office, let's say.

A

Let's add a sample spring script in their method and.

A

Pipeline for my results is running again: okay, let's try to put this much request into a muttering again.

A

Now pipeline on my strain is running again and at this time should succeed.

A

Okay, it's sexist remarked and, most importantly, this March. After this much request being marched, it shouldn't break Massa branch.

A

See this post post pipeline post much pipeline shows that it's passed the pipeline has passed.

A

Here's a committee history on Massa branch is that we are seeing that all comets made on master branch has a successful pipeline. So as a conclusion, we can say that using my strain is very helpful to save muscle branch from broken state, all maintenance can can be more relaxed and ever when they hit Marsh button in my requests, because ghilaf is going to validate each Marcus on expected much comment.

A

So thank you for listening.