GitLab 14.8 Release Kickoff, 11 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 14.8 Kickoff - Verify:Pipeline Execution

Description

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

Issues Discussed:
https://gitlab.com/groups/gitlab-org/-/epics/5653
https://gitlab.com/gitlab-org/gitlab/-/issues/340504

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

A

Welcome to the verified pipeline execution, 14.8 kickoff, my name is james heimbuck, product manager for the pipeline execution group here at gitlab. uh As a reminder, this group is responsible for gitlab ci such as pipeline pipeline processing, as well as the category of merge drains I'm joined by the pipeline execution product designer vitica and in 14 8.

A

We're focused on ci minute visibility and ci metering for open source projects, while mitigating pipeline abuse you'll find a link to the 14.8 kickoff page for git lab with links to the items that we're going to talk about today and the verify stage direction page with discussion of our future work and pipeline execution, as well as the other groups.

A

In the comments below the video, you can always reach me at james j heimbuck at gitlab.com or through comments on these items or any item with the group pipeline execution label on it in the gitlab project, uh so focusing in on 14.8, and I'm already sharing our 14 8 wrong issue.

A

This uh planning issue um today I wanna uh or talk through the the things that we're gonna be working on and our big focus is continue to work towards our goals for separating the cost factor for open source, public projects and public projects on gitlab that are not part of our open source program, and so today I want to talk through a little bit more, not necessarily the issues in the milestone, but where we're at in this project- and so we've broken this down into a couple of iterations uh and iteration one.

A

Adding the high level quota for public projects that was completed previously, currently we're in iteration two of making the duration of the project pipelines visible and the last item. There is adding that monthly pipeline duration for projects and name spaces for ci performance visibility.

A

This is an item that the team has started in 14-7 and is looking to wrap up in 14-8 that'll, make it a lot easier to track your shared runner, duration or your wall, clock time for pipelines and your ci minute consumption, which is how you're actually build so what's still left in this overall larger epic is iteration. Three and that's really implementing that one-to-one ci cd minute to pipeline duration quota for those public projects that aren't part of the open source program through gitlab, and so we have a number of issues here.

A

The team has already started and picked up work on a couple of those in 14 7.. You see the milestones here um and really we're going to start implementing or enforcing these in 14 8 with hardening the stan limit for public projects, that is, for projects that were created after the july 21st or july 2021 milestone or the july 2021 release, and then, after that, we're going to be enforcing that for all public projects that are not part of the open source program with git lab.

A

I also wanted to call out that we're deferring some work where we're going to move on to other opportunities as a group before we come back and revisit these. uh So a couple of those are the minute notifications alerting a user as to when they're approaching their minute limits. That's something that we want to get back to soon and then minute configuration allowing you at a group level to assign minutes to different projects, so they can use different amounts of your quota. Those are both opportunities that we do want to explore later.

A

We do want to make sure that we're solving the right problems for our users before we pick those up and so for now we're deferring that work as we explore some other opportunities.

A

So that's a quick recap of what we're working on in this larger epic and where we're at and where we're going, but I also want to hand it off um to vedica who's working on some really interesting work in design and research, and so I'll pass it off to her now to talk through those items.

B

Thanks james um all right there, you go yeah. So, besides focusing on visibility of slime minutes and other changes that james just spoke about on the design side, we have some pretty exciting developments as well. So, for example, this issue um previously uh in our previous kickoff video. We mentioned about a research that was underway and which was for to understand like how we communicate to uh our users the more strategies and options that they have set up for their projects when they are merging the change.

B

So the labels that you see on the merge widget in case you have opted for merge train. um One of those could be start, merge train when python succeeds and so on. So what we want to do is we want to make our communication simpler.

B

We created some designs uh and we took them to you to our users and we tried to understand like how can we make this whole experience better now, based on that, the first change that we are going to do is uh if you would make some small little changes to our rigid design, to better communicate to you like. What's the progress of the merging process- and this will be paired with a change in the label as well, so stay tuned for that uh change and the other issue that we would be looking at.

B

uh So you know that we have been working on making our pipeline and job index page more usable and to complement that effort. We thought why not also look at the details page so, for example, in this one we are talking about the job details page from a recent discussion on an mr.

B

We learned that the erase action that we show on the uh job detail page, which is which appears right above the job logs it does more than just delete the logs uh and this like caught our attention and we have like introduced some change to communicate this action better. But apart from that change, what we also see as necessary is elevating the level for this action, because it definitely is uh more than just a localized action for just the logs, and that is it. That is.

B

uh These are the two major issues that we'll be looking at in the upcoming milestone uh design wise. But along with this, we would also be following up on a bunch of issues that we are working on this milestone, because they are much larger in scope. And that's all from me back to you, james.

A

Thanks vedica, I'm really excited about those, especially the simplification on auto merge when I started at get lab because we use merge trains on the website and within our docs in some places it was really confusing about what was going to actually happen with the mr. When I hit that button and so there's a lot of hesitation of do, I want to hit the button what's going to happen. If I hit the button so clarifying that process, especially for new users onboarding onto gitlab, I think it's going to be a huge improvement. That's exciting.

B

You're, absolutely right: yeah, that's going to make a lot of change for our users. Yeah.

A

So we're very excited for 14.8. uh If any of these issues are of interest to, you feel free to give us a tag on those issues. You can tag me at j, heimbuck underscore gl and be happy to start a conversation about the issues thanks so much.