GitLab Source Code Group, 28 Jul 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Design concept - Cascading repository group level rules (Exceptions, Display inheritance)

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Hi, my name is Michael Lee I'm, the source code group and today I'm going to be talking about um the next Design Concepts around handling cascading settings and, most importantly, around the context of merge, request approvals and essentially Branch rules. So just to recap of things at the moment we can Define merge, request approvals and the project level through merge, request approvals and eventually Branch rules at the security policy level.

A

We can Define different approvers over here, so you can Define approvals based on different conditions of scans and what we're talking about introducing soon is the ability to introduce merge, request approval rules at the group level and having that Cascade down to project level, um so the cascading rules um will it apply only from the group root level down to the projects or should we have group level rules and subgroup level rules and kind of handle our cascading rule around that I think to keep it simple at this time we should only do the root group and then from there um build out um how the experience works and if we need to explore subgroups in the future, um that's something that we can look into, but I think in Reading other issues around this space and that was kind of like the direction of handling it at the root crew from potentially a performance issue.

A

um But things may have changed so please, let me know if I should change my thinking here, so I'm going to move ahead, assuming just attacking this at a group level. So at the moment this is our group level rules around repository settings. What we can introduce at the group level is Branch rules, so when I say Branch rules, this encompasses Branch protections and merge request approvals. So all those different kind of rules can be applied in one area.

A

So the other thing that we need to introduce to make this work is the ability to provide exceptions. Exceptions are really necessary here, because what we don't want to do is lock up projects um because they increase the number of approvers across the whole spectrum of.

A

Projects in a group and which could be both a hassle for the project maintainer, but also the approver, who has to approve projects that they really don't care for or don't need to look into. So we can look at um providing an exceptions so that these rules apply to everything, but these uh projects, so in this case there's 100 and there's 150 projects an exception here is here: I think we can start like this and add individual projects as exceptions, and that gets really bad.

A

um The other approach that we could look into is excluding by subgroups, so there could be a team that doesn't need to follow the compliance rules and the group level um closely. So in that case we can add a subgroup as an exception. So then, when we do the logic checks we're going to include those subgroups. So in this scenario we can see that oh okay, there's 120 of these projects being applied, um except for this, so it gives you visibility of where these rules are applied and not applied.

A

um One thing that you've probably seen so far is the design of the branch rules at the moment in production. It looks something like this, but there's a movement within settings right now to use the card layout. So something like that could look like something like this and at the project level, we would get these um Branch rules inherited that we defined at the group level.

A

So in this scenario here these first two are rules that have been defined at the project level and then this one over here is defined from the group and not only Define it's inherited. So when we do the rule calculation we're looking at all three rules, not just these. uh These two that's defined at the project level. Currently, and then you can't really edit them here, but you can view them and if you have permissions to edit the group level rules um yeah that could change as well.

A

So this way gives you a read-only view of um the rule itself, so I think that's valuable for a repository manager. Kind of looking in here um checking the rules and seeing what may conflict um in their rules.

A

um So what will happen to project settings that already exists um this one I'm open to engineering input? You know group settings override project settings or where we just use group settings instead of project level settings so project level, settings don't get erased, but they would.

A

um Still live there in the database, but if the flag is on that and the group level rules are applied, we would just read the group levels and said: I think that might be beneficial in the scenario where we applied this group level rule across the whole entire group, but there's projects there that had settings set up and they get added to the exception lists and that should revert them back to their previous settings without extra additional work and I.

A

Think that's why I would opt for more to use instead of project level settings um so keeping the project level settings there unless they explicitly override them themselves, um but open to engineering input there. So um the other part that we need to look into is the rules and how they manifest themselves, especially with merge request approvals if there are matching rules, so the idea of moving to the card can allow us to present information um with some structure.

A

So this is an example of how approval rules with inherited rules at the group level, policy and project level. um You know if you have code owners approvals. If you click it open, you can see what that resolves to. This is something that you only see currently inside of merge requests but bringing it into the world of settings and help that person who's.

A

Maintaining the repository understand the scope of the changes that um and the scope of the approvals that are in there, and this can get really long for a big project, so maybe rendering this out might not be the right thing, and perhaps just linking to the code owners and the relevant code owners files is the better approach here um and speaking around inheriting we can have the merge request. Rules in hair, different group levels at the project level would look something like this.

A

um Security policies could be injected into certain Branch names scenarios. So let's say you know any feature: branch that has any security violations, and you know we would analyze any policies against the project and then display that it's um to required after reviewing this with Camilla she's, actually said that this is not very useful for people. You know that's two required, and she put me on to the idea that we already have summaries for security policies, and this is an example of one where we have like default.

A

Denied rules is the title of the policy, and this is one of the more complex one and it has a summary where it says it requires two approvals when this condition happens and when this condition happens.

A

um So if we applied that to the world of emerging cross approvals, what that might look like over here is that we have our inherited security policy with its name two required, and if you click on show summary, we will display the same summary. That's there for a security summary um and as a maintainer of a repository, um you can see not only the rules that you have set up for the at the project level, but you can also see what other checks may come in from both the group and the security policy.

A

So I think this one view to manage things can give you more control of What's, um that's being applied. So, yes, so to recap things um for merge, request approval settings, merge, requests approval rules at the group level. You can think about moving ahead with that with the branch rules approach, but the most important thing that we need to ensure that we do is to allow for exceptions.

A

We need both of these things to happen so that we don't upset existing projects and it provides a way for overriding um for projects that I already have project settings.

A

um We would use these rules instead of those settings and, if there's a scenario where those projects don't need to follow these group level rules- and we can add them to the exception list- and it will revert back to the previous project level settings that were there I hope this clarifies things a little bit and I look forward to some of your feedback. Thank you.