GitLab Testing Group UX, 16 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.11 Kickoff - Verify:Testing

Description

Kickoff Page: https://about.gitlab.com/direction/kickoff/#verify

Ops Direction: https://about.gitlab.com/direction/ops/#verify

We love feedback and you can reach me at jheimbuck@gitlab.com or mention me on GitLab.com using @jheimbuck_gl

A

Hi, I'm james hembach, the product manager for the testing group, the verify stage at gitlab uh today, I'm joined as always by hayanna the ux designer for our team, we're going to be previewing the work, the team's going to be doing in the upcoming 1311 milestone, which will release in april of 2021 you'll, find a link to the 1311 kickoff page and with links to these items in the verify stage direction page with discussion of our future work in the comments below the video.

A

As always, you can always reach out to me at jheimbuk, gitlab.com or through comments in these issues. Any of the issues anything that's labeled group testing in the gitlab project. So I'm already sharing my screen, showing our planning issue for 1311 and we've been using themes lately and so speaking to the theme in this milestone. We're going to be focusing on items that improve developer workflow with our code quality feature and specifically we're going to focus on the code review portion of that workflow with a couple of items.

A

A common theme that we've heard from developers is that it's hard to know what to pay attention to. In a merge request, when it comes to the code quality and specifically it's hard to find violations that actually need fixing. So to address this, we have one small iteration and an mvc issue. So two separate issues of a new feature in the milestone.

A

So a small implementation issue is just sorting violations by severity or do that in the two places the code quality violations already show up today within the merge request widget if you're looking at it there and within the pipeline page view so you'll see the highest severity issues. First, things that you should probably address and they won't be lost in a list of 35 pages of violations that you might have.

A

The second is our mvc minimum, viable change to add violations into the mrdiff view, and I'm actually going to hand it over to hannah to talk through the design of this and where we're going with this feature in the future. So I'll stop my share and hand it off.

B

So, let's let me start sharing the screen and, as you know, um this quarter we're working uh together with products on a kr to increase the system, usability scale score of gitlab to 72.5, if I'm not mistaken, and we're working on improvements around visibility of system status and also system performance. So this is a way for us to understand the overall ability of a product and to track changes over time testing. As james just mentioned, we are contributing to these improvements towards the merger quest widget.

B

The first one show a file has code quality data on merge, request, diff view it's around adding a batch in the in the merge requests uh for files that modified, and that has changed. They have changed in the code quality violation. This will give users a quick way to see how new code quality violations impact the overall project.

B

So in this issue, let me quickly show you the ui, it's a very small change that we can iterate later on and we'll add at a glance, uh a ui item, ui component, letting users know that hey this file here has been updated and the number of quality validation has changed.

B

So next up, we have code quality in the div merge request. It's a highly requested feature: we're looking to enable users to see the code violations in the prior to accepting the merge requests. um So this is the prototype ui. Let me zoom in so you can see we'll be adding uh this well icons, these ui components similar to what we are displaying today in the secure widget, so that users uh have a clear and visible way to identify vulnerabilities in the code.

B

So when you hover you'll be able to see that it's a code, quality alert and the type major uh if music simply blocks the code and then users, when they click they'll, have the ability to see a modal uh see the file in the for description of what this vulnerability looks like. So we have a full implementation issue schedule for 14.1. You can see this the depth issue with all dui added here and how the code coverage types will affect the interface, so um I'm going to pass it over back to james.

B

So can he talk a little bit more about code quality and what's next for testing awesome? Thank you.

A

I am really excited about this feature uh because it'll show you within your change, what you've actually introduced or what is around your change. That is a code quality violation. uh So you have that context, so you can go back in and change things that you're familiar with to improve the quality of the overall project without digging into files you haven't seen in years potentially so. The last thing I want to touch on is a problem that we've heard about with the changes with docker hub and the rate limiting the code.

A

Quality jobs are really ramping, folks up ramping up the amount of times that you're hitting docker hub. So when I help address that in this milestone, making it easier easier to leverage the code, quality or code, climate image variable and the code, climate version environment variables, so you can utilize internal repositories or mirrors to mirror those docker images, so you're not having to download those containers.

A

Every time you run the scan, which is the prototypical or the the default behavior, it should make the scans run faster and reduce the number of times that you're hitting that docker hub limit. Potentially so as always, we welcome feedback through discussion on these items. This video, you can always email me at jheimbuk gitlab.com about these are other issues in our testing backlog. Thanks so much.