GitLab Source Code Group, 18 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Branch rules design walkthrough

Description

Related: https://gitlab.com/groups/gitlab-org/-/epics/8075

00:00 Overview
01:35 Create branch rule by name or pattern
02:48 Edit Allowed to Merge
04:15 Edit Allowed to Push and Merge
06:07 Allow force push
06:30 Require code owners
06:53 Minimum required approvals
07:28 Add approval rule
09:06 Add status check
09:41 Delete branch rule
09:58 All branches and All protected branches
10:49 Displaying all approvers of a rule

A

Hello, my name is Michael Lee of the source code group, and this is Branch rules. um The completed design so I updated all the issues related to Branch rules, um editing and this scope is just editing. Branch rules, handling, inheritance or group level rules will be handled in a separate issue So. Currently we have Branch rules and, as we expand them out recently, there was a change to put all these into GL cards layout. So that's why it looks like this.

A

um So viewing Branch rules- and this is where the new stuff that's happening- is that we're going to take what we have right now, where we redirect people to protect the branches or the merge, requests approvals area and we're actually going to implement editing.

A

um This here is the updated read-only views, so I think we can handle that in a separate issue to like update this styling, but generally it's kind of the same there. So we're just going to focus more on the editing experience and perhaps during the editing experiences when we will update the read-only views because they're very, very similar between read-only and the editing where it's mainly these actions here like edit and like these actions, are hidden and displayed.

A

So let's get into it um we'll go we'll do the most complex one. um You don't have any branch rules in the repository. You have Branch name Branch pattern, so you click on this. You can choose the different types, so we'll do Branch, name and Branch pattern, first outcomes a model, and that allows you to select a branch name or use a pattern as your clicking it this list of all the different branches that you can choose from.

A

As you type it will filter Auto filter as you type, and once we detect that there's a star, then we display the wildcard option and so, let's say I selected that and let's say, create Branch rule that creates a branch rule like this.

A

If I was going to edit that um a model pops up with the update, Target branch and then you will press update and then that changes all changes will then have a toast to give the user feedback on what the change was and, if possible, undo button to revert them back to the previous.

A

um So let's get back into um the golden path here. uh This is the default setup for branch protections allowed to merge, admins and maintainers, um and now we're going to start editing that I click on edit and then this is. It says edit allow to merge.

A

um What we did from the current experience of editing allowed to merge, which is just one drop down, is actually splitting the responsibility of that one drop down to the things that you can actually select roles if we want to introduce more roles through our back um that are applicable here or other rules that make sense to add here we can add those easily users and groups. We recently added this filter to scope, the search so that's in there and you just search to add users and the same thing for groups as they get added.

A

The number here gets incremented I'm, removing people here, there's no feedback at this stage. You just remove people as at will, because you can always press cancel and then that reverts you back to the previous state, so there's no need for any toast at this level, so um just add and remove as as you're happy once you're happy, you click save changes and we can see that allowed to merge up and got updated, and you can undo and revert back to your previous date. So now we have these two things here.

A

um The extra thing I added in here that's different from the current Branch protection. Is this extra line? Merge requests are required for changes, except for those allowed to push and merge. The idea here is to make it explicit that with Branch protections, all changes go through um emerge requests and anyone that's um in this list as a bypass or there's, like the exception to the rules. So these are the people who are actually allowed to push and merge so trying to make that more clear here.

A

Otherwise, without it, you kind of guess why this allowed to push and merge um even exists.

A

um The empty State here is actually says: everyone is required to submit a merge request for changes and that's true. um If no one's allowed to push, everyone is required to submit a merge request, so I think spelling all those things out makes this experience a little bit more clear once again, if I press edit here I'm presented with this screen very similar from before um you know, I select whatever I want the difference with push is that you're also allowed to add deploy keys. So that's why this exists here um and then yeah.

A

That should be the scope part here as well um forgot to add that in we'll do that later um and then, once that's added in you got displayed here so currently we display everything in a drop down, and if it's you know, developers and maintainers, that's already getting truncated, dispose everything else to At a Glance. You can see what your branch protections are, because I have people who are allowed to push here. The option to allow the force push appears previously. It was hidden like there's no point of having that.

A

If no one can push so this exposes that ability to say that all users who are allowed to do with push access are allowed to force push. So that's there.

A

um If I activate it, then I get um a lot of force, pushes enabled and same thing with required code owner's approval if I toggle that I get a feedback from the toast to say that's enabled, and that is the branch rules. Editing experience. Now we're going to move on to editing the number of required approvers.

A

So at the moment we have all eligible users as like the rule and approval is required, is zero by default. I'm proposing that we add a name called minimum required approvals so that we, if we handle this at a group level, we can set this rule up at the group level and that will Cascade down. But this is a clearer name about what it is.

A

um You can change the number in here and then that gets the toast update and then- and that's that simple rule, if you want to add a custom rule where you have different users and groups- and that's in this add button here and you can do add approval rule, add coverage check rule. So if you go down with the ad approval, we have the rule name the number of required approvals. You can change that numbers users, groups and then you just add them like before, and then you save your changes uh with coverage check.

A

This is one where it's like a standard one and it it has a description about this is for when it decreases in test coverage. That's when it's run and then you can select those people in there as well, upon approval rule being added, there's feedback through this host once again and then you can see all your users here. The way we present users and groups is consistent between protective branches and merge, request, approvals and I. Think that's good from just a consistency standpoint.

A

If you updated approval rule the toast changes to updated. If you delete approvers, you know if I delete it the front end.

A

It's a similar model that we have now has just split up the sentences, but you know the current one would work as well and remove approvers and you get the toast as well, and that approval group is gone.

A

um So the logic and functionality of things haven't changed too much is just the way the UI works, with status checks, this one's a little bit more simple, add status check.

A

um What was in a model now lives in a drawer um in the same Fields. Nothing has changed there. You can add a status check um and then once that's done, it gets added and you can see, as that is checked added.

A

um If you remove that you're about to remove this status check. If it wants upon removal, you get that status check deleted with Branch rules um when you delete them, you're going to delete a branch or this action can't be undone upon deletion. The user is directed back to the branch rules list in settings and Repository.

A

um The other thing that we need to talk about is the scenario of all branches and all protective branches. These are more used for merge, request, approvals and Status checks.

A

um So there's no Branch protection settings on these ones and the target branches is fixed to all branches and this one's fixed to all protected branches and same thing as before. You can add and change, merge, request approvals and Status checks, but the scope is limited in what um the target is to find this all protective branches or all branches, and that is accessible from the this year of branches. When you want to add a rule, whether you want to Target all branches or protective branches, it's not there.

A

um Last bit of information is that in merge request approvals when there are many people. So in a scenario where there's like more than 10 10 elements here, we will truncate it to say, show all 17 as in this is the number of everyone resolved.

A

So you know with the groups and users if there's more than 10 elements, and this example is not that good, because I only have four but there's enough space to display 10, but once it reaches 10, then we add this link clicking on the link will display Moto, and this will allow users to scroll and see who's in the group. This is one implementation. Another implementation is potentially to put it inside a drawer and I.

A

Think that's something we can revisit once we get into the implementation phase to see which one feels better um and it's usable. um So that is editing Branch rules, please let me know if you have any questions, all the issues that have been updated and thank you very much.