GitLab Compliance Group - Meetings, 24 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: API Approval Rule setup walkthrough

Description

Quick prototype demo to demonstrate the workflow of adding an new approval rules for an external API

Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/219567
Figma prototype: https://www.figma.com/proto/wWTJwed5c4EtRF4oy7Es4f/219567-Create-API-based-approval-rules-for-merge-request-compliance-checks?node-id=75%3A5&viewport=1227%2C197%2C0.12490058690309525&scaling=min-zoom

A

Hey team, so I heard from matt uh there's a little bit of confusion about the uh the flow associated with this issue, and so what I was hoping to do was walk through uh prototype to kind of show how I understand the flow to be as well as a couple of the interactions that we'll be introducing and seek some feedback from you all in some of the copy and look for where things may or may not make sense.

A

So that said, I set up a simple prototype in sigma. I basically learned there are like two paths specifically for creating approval rules. So first one that I discovered is, let's just say the user, for the sake is starting on the project page. They navigate down to their settings under general. They scroll down, they can look for their merge, request, approval roles and here's where they first get their opportunity to add a new approval role with that.

A

This modal mostly hasn't changed, but a couple things to note that there used to be a number of required approvers here and we're going to move that, based on the logic that I understand to make the most sense.

A

So, for the sake of this, I'm calling this rule name project level just to associate like this is a project level established, merge, request, approval rule, and so I'm still trying to work out some of the copy here. So please feel free to add feedback if something doesn't make sense.

A

But one thing I wanted to also kind of incorporate here is: let's say, we're doing: users and groups, um something I've been trying to understand. Myself is how does this number of approvals required work?

A

One thing that I learned is based off of some feedback dan provided. If we change this to zero, apparently that makes approvers optional in a merge request. I think it would be beneficial to help show the users while they're going through this. What would happen if they did turn that number to zero, because I still don't fully understand what happens if that's at zero or five, but the way I unders, I think I believe to understand this. Is it defaults to one?

A

And if you add just one approver here, that's fine, but you could also add two. That's also fine, um and there are also default people that get added as approvers. I think, based off of some sort of permission. I think that's somewhere in our docs.

A

Let's go back to the api rules, so instead of picking user users or groups we're going to pick external api and something that I don't really feel great about is I don't know what makes the most sense here, and maybe the people that work in back end would have more of an opinion on this. Like external api, approvalgate external approval, url, some other variation of that effect.

A

I don't know what makes the most sense, because this is a pretty foreign concept to me, and so what we want the user to do is to then provide the link in which we can test against or validate when they're running that pipeline during the mr process, and so I'm putting just some dummy text here and rob, and I were talking about how to be really great- to provide user a quick way to check at least to see if that link is valid.

A

Now I don't know what fancy wizard nonsense. You guys do to check this, um so I was hoping that if I hit test link- um and it fails that get some sort of warning well rob was trying to help me understand- is that might not necessarily be a bad thing like what if it were the end point hadn't been set up, yet that's not necessarily bad. It's just something you might want to be aware of. So in that case you don't want to tell the user hey. We just failed to receive the payload.

A

That also made no sense. I don't know if I'm saying these things correctly, I'm not super familiar with apis, but let's say someone does go and configures it uh and we get a good check. Just give the user a quick validation that hey this approval gate is gonna work just a little bit of feedback to help them feel more confident about what they're introducing into their workflow.

A

My biggest concern is that an approval gate would be added and it wouldn't be a valid link and it would become a hold up in the merge request process.

A

So after this user can, you know, add their approval successfully and it'd be added to the list. We would see the project level name and then there'd be an icon to show like this is different from these other rules, and this icon would allow you to see the link that was associated with the url.

A

So that's like the first path that I understood, but then I came to discover that there's another path when creating a merge request in which you can also introduce a merge request, approval rule, so I'm going to reset the prototype and let's, for the sake of entertainment. Here pretend I went through the steps of creating a new merge request and I get jumped to that page.

A

So here again, very similar looking ui the approval rules is called out here and there's an additional button to reset to project defaults. So whatever was configured in settings that would appear here if you wanted to reset it, if you made some changes, you wanted to adjust them, but continuing on with the example same type of interaction, something I noticed, though, was we don't show the target branch field here. So what I'm thinking is?

A

We don't have to show it, but if it's valuable for users, maybe we can make it read only my assumption was that it's not necessary, because this rule is specific. Just to this branch, anyways.

A

So for this one, I'm making a merge request, only approval rule and for the sake of happy path, I'm gonna do external api put in that same link and add approval rule at this point. We'd also see name appear same style, interaction, get the cloud. You get hover action for the tool tip and at this point this is where the prototype ends, and I understand that where this comes into play is in our merge request, we want to be able to show these approvers in the same list together.

A

So that's going to come next, but I hope this clarifies or illuminates to you to you guys how I need to better understand the workflow or how the user might progress through adding approval rules. Let me know your thoughts and look forward to hearing from you guys all soon.

A