GitLab Compliance Group - Product, 22 Oct 2020

Previous Meeting

⏯

youtube image

►

From YouTube: Compliance: Merge request approval rules

Description

Product Designer, Austin Regnery, explains how inheritance might play out across the different levels in GitLab for Merge request approval rules using a simple example.

A

Hey team: this is austin here product designer here get lab. I want to cover a couple ideas that I was bouncing around in terms of showing how we're thinking about the inheritance merge, request approvals across instances, groups down projects.

A

I was kind of hanging my head against the wall on this one, so I thought it'd be easiest to just show what I was thinking so with that. This first example that I'm gonna walk through kind of ignores the state as it is today um in terms of applying compliance framework labels, but the basic relationship would be.

A

Projects are inheriting rules from their parent, which is a group or an instance. A group is inheriting its rules from an instance.

A

So this scenario- I have an instance where I have approval rules configured a group where there are also default approval rules and a project that is its child over here. There is a child project of this instance, so we're going to change this instance to two and what we would expect to happen is to have a trickle down.

A

So what we saw is each of these child items, so the group projects projects all change to two now, if we change this group to four its child would also be impacted, so it would change from two to four.

A

Now, in this case, if we disable the ability to change this value, this project can no longer increase or decrease that number it's stuck at four, so the group does, our things would be interesting is if we disabled the changes at the very top, so the instance level.

A

This would set everything to two and lock down this ability to change the setting.

A

Now, if we re-enable it, it would allow its children to go back to what their previous settings were. So the group is back to four. It doesn't allow changes, so this project is still locked down, but this project is back to two.

A

So that's where the idea of it ends in terms of if there weren't any compliance labels where we could further refine this idea and potentially allow compliance labels to drive further customization.

A

Same type of scenario, except I'm introducing um an additional sub project to this group, so we have two projects that are the children of this group.

A

If we change this to two, it's going to only impact a few things, because we are specifying at the instance that we only we only want this stuff to apply to sox related things.

A

Now it's going to impact groups, but it may not impact the group's children we'll show how this plays out all right, so changing it to two.

A

The group is inheriting the two, but the project is not, and neither is this project.

A

The reason being is: the group is inheriting instance rules, but it's not necessarily applying them all the way down. It's only applying that rule down to the ones that configure the same label here. So essentially, what we're saying is sox is configured at the top as what we care about. So the group. It's not going to be able to modify or change go to a different label.

A

It can't change it to like, let's say, soc2 or hipaa they're stuck kind of configuring it for socks, so creating sensible defaults for socks, change this to four you'll notice that the project has changed because it's matched to its group.

A

It has deviated from the instance but because instance says it. Allow changes, that's acceptable. It's allowing the groups to decide for the projects that have a socks label how it would show up now if we disable this feature, it's going to lock down the number of approvals required for this project notice. It still has not impacted this project and definitely not this project going back to our example from before.

A

If we disable it at the instance, it's not going to put all those things back to two, so the group is back down to can no longer be changed. The project is locked down, no longer able to be changed and these projects can still operate freely, so that provides a little bit more customization. I just really wasn't sure which one we settled on so I'm interested to hear your thoughts.

A

I think it really doesn't help putting into a diagram, maybe something that would make more sense to a developer or maybe like an architect, but I just worked better with visuals, so it was helpful for me to kind of write it out. First, then, put it into the ui and then kind of show how that would.

A