GitLab UX Team, 27 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Protect UX: container scanning config MVC ideation

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, this is kyle from the secure protect team. This is just a quick demo about a possible mvc for container scanning, just some background, we're looking at the security and configuration page, and this shows the different scanners that are available to users in a project today. You can actually click when it um when sas scanner is not enabled you can actually click enable, and that takes you to a workflow, adding the required template and a user interface to collect some variables.

A

So this is following a similar pattern. That's seen there and also for an upcoming dependency and license scanning flow, so with container scanning it's a little bit different.

A

This workflow simply adds the template and then just helps the user get up and running and also learn how to set up container scanning. So I'm going to just walk through that. If the user lands here they see, container scanning is not enabled, and then they have this enable button. The user can click the enable button and then they actually land on a new merge request page.

A

um So this will only be into the the master. Now there's a couple of things here. um That's signaling back to the user, that more work is needed and that's using the work and process or the draft prefix in the title and then also calling out that action is required so pulling out the documentation right into the merge request.

A

It's saving them all. Those extra clips of jumping into documentation, then going back and forth and setting up the merge requests themselves, and also they learned that this is tied to the ammo file. In previous studies, we've seen that it was not obvious that that was the case, so this helps them immediately. Understand that that's the case and it gives them the requirements that they need to run this and also the added areas that they need to fill in for this to run properly.

A

One other call out is: is this commit down here was made with a skip ci, and the reason why that was done is let's say that the user just hit, submit, merge requests and they create the merge request.

A

It will skip the pipeline from running because the pipeline will fail because of these other variables have not been filled out. So we don't want to walk them into a failed pipeline, so we're doing the skip ci and calling their attention to the actions that they need to take.

A

Now they may take a look at the diff and let me just scroll down there and we're even um pointing out what the action required here. So what happened is we included the template and um pre-filled some of these variables, but we're also calling out exactly what they need, what the requirements are.

A

If, if they don't, uh if this doesn't work for them, they could just leave the mr, and if it does, they know what the next steps are to do and they could either add another commit or submit the merge request and take it from there. But again this saves them a trip from running around documentation and the goal is, is just a quicker setup and and and hopefully more adoption.

A

So once we submit the merge request, then we go now we're in the merge request and we see here, um the text is just helping them walk through what exactly needs to be done? It's it's being abundantly clear that actions are required and from here they can make additional commits okay and then the last part is once this is completed and container scanning is then enabled that signal would then be on the status on the configuration page all right. Thank you.