GitLab GitLab 13.5 Release Kick Off, 16 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.5 Kickoff - Create:Source Code

Description

The PM (Daniel Gruesso) from the Source Code group covers the items planned for GitLab release 13.5, shipping 2020-10-22.

A

Hi, I'm daniel grusso, I'm the pm for the source code group in the create stage of the devops lifecycle here at gitlab, and today, I'd like to share with you the kickoff for our 13.5 release, which will be shipping to the world on october 22nd 2020.. So, let's get right to it. First thing that we're going to focus on is adding a group setting so that you can configure your default branch name.

A

So, as you know recently, we added a feature that allows you to set this up at the instance level, and what this follow-up is is meant to do is to give you more flexibility.

A

This is going to be especially useful for gitlab.com users that are going to be able to set up their default branch name uh for their group and it also, uh if you are a self-managed user, it will allow more granularity if, let's say different groups, once you've used different default branch names and we're going to be able to set this up now.

A

Next, we're going to be working on uh reviewers for merged requests. So we started this works part of 13 4 and we will continue to get across the line in 13.5. There's a couple of things that we're going to work on first is going to be this plane approval rules that match a reviewer. So, let's say, if you have set up merge, request approval rules.

A

When you are going to select which reviewer will be assigned to your merch requests, we will display the approval rule that matches that reviewer, and what we're doing here is that you want to assign reviewers to your merch requests that are able to satisfy whatever rules have been created for the merch requests, so to keep it relevant.

A

We want to show you which ones will satisfy those rules, so you can select those without having to do any like work on outside of the reviewer selection, so very excited about this one. um Let's move on uh next one is going to be displaying merge, request conflicts directly in the diff. So, as you know recently, um we shipped a way that allows you to compare your branches in a much more efficient way. However, when there are conflicts, this doesn't really work.

A

So we already shipped the first iteration of this, which tells you when there's a conflict, but it's up to you to resolve that conflict.

A

So here we want to take it one step further and we want to show you what the conflict is directly in the diff view and then offer you the same resolution capability that we offer elsewhere. But we want to show this to you directly in the diff that will allow you to more efficiently deal with those conflicts and do it all in the same place.

A

Next, we have a usability improvement for draft merge requests. So recently we renamed whip or work in progress. Merge requests to drafts, however, in order for users to convert a merge request into a draft, you have to go into edit mode and you have to prefix your merge request, name with uh with draft term.

A

So we want to make this easy for users and, as you can see here, we are going to update the button on the upper right hand, side of the merge requests and we're going to allow the marcus draft action with a single click.

A

So, very clearly that this is will make the feature more discoverable and it will make it easier for users to let everyone know hey. This merge request is still in progress. It's a draft, so it's not ready for review yet and then, when it's ready to be marked as reviewed, the marcus draft button will then become marked as running. So you can more completely let everyone know that it's ready to be reviewed next, we're going to work also on a usability improvement for our file by file review mode for this.

A

So right now, if you have a merge request that has a large number of files, um you can toggle file by file mode on your user preferences. So this is another feature that is great because you know it makes the diff view much more performant, but you have to know where to go. Look for that setting and you have to change it and you have to save it.

A

So what we want to do here is make it a lot easier for you to switch to file by file mode by simply clicking a a check box that will show you file by file, and then you can just do previews or next for your files. You will only have to load one, so it's going to be a lot faster when you have merge requests that are dealing with a large number of files.

A

Next we're going to work on highlighting auto collapse files in merge, request, diffs and, um as you know, uh for performance reasons. We collapse files that are very large uh on your diff view and, as you can see from the screenshot, this kind of made it easy to at times miss that there was a file that was collapsed and we definitely don't want that to be the case.

A

So the first step that we took is that now we are accentuating when a file has been collapsed, so you'll see kind of a larger space and it's more easy to notice, and the second step that we want to take is that we want to highlight so change the color of the file that has been collapsed to let you know very clearly that hey this was collapsed, but has changes so you should review it and basically make it a lot harder for you to miss any files in your review.

A

And, lastly, we have an update for code owners so right now, um gitlab's main access control capability for branch changes, um it's protected branches, so you'll find this in your project settings and this is meant to basically govern who can push and merge to certain branches within your project.

A

If now, if you have code owners um configured for certain files of your project, no one will be able to push to that specific branch, even if they are configured on this screen as allowed to push so recognizing that the main mechanism to govern and protect your your branches is the protected branches. What we want is this setting to supersede the code owner settings so, for example, if you have configured um quote owners to protect, let's say everything on their readme file.

A

For example, if you configure a user that is allowed to push to this branch that supersedes code owners and they will be able to push directly to your readme file without having to go through the code bonus process.

A

So of course, there's a lot of flexibility here, because if you want no one to be able to push but force the merger request workflow, you can still do that by simply uh selecting no one as allowed to push, but it gives us greater flexibility, especially for automated workflows, where, um let's say automated accounts are going to be able to merge, let's say or change tags or update uh things that are part of the release workflow.

A

So we hope that this is going to make it more flexible and easier to work with code owners and those are the main items that we have for 13.5. We will continue to work on a number of performance improvements for the merch requests, uh the main page and also the march request list, so very excited to make that more performant and, as always, your feedback is really appreciated, feel free to reach out to us on the regular channels. Thank you see you next time.