GitLab 14.10 Release Kickoff, 16 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 14.10 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/gitlab-org/gitlab/-/issues/207988
https://gitlab.com/gitlab-org/gitlab/-/issues/35135
https://gitlab.com/gitlab-org/gitlab/-/issues/30947
https://gitlab.com/gitlab-org/gitlab/-/issues/336542

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 for team 10 kickoff, my name is james heibuck, product manager for the pipeline execution group here at gitlab. As a reminder, this group is responsible for gitlab ci, such as pipelines, pipeline processing, as well as the category of merge trains.

A

I'm joined by the pipeline execution product designer vitica in the 1410 milestone, we'll be focused on closing some vulnerability issues, improving ci minutes visibility and cm metering for public projects to help with mitigating pipeline abuse, while still enabling oss projects to get contributors contributing to them without burning through their minutes.

A

You'll find the link to the 1410 kickoff page with links to these items and the verify stage direction page with discussions of our future work. In the comments below the video, you can always reach me at jheimbach, gitlab.com, through email or by pinging me in comments on items with the group pipeline execution label in the gitlab project, so in the 1410 milestone, we're going to continue to work on our goal towards separating cost factor for open source public projects and just regular public projects that aren't part of the open source program.

A

We've been working on that for a couple of mile studs we're getting really close. The focus for the team within 1410 is really twofold. Beyond that, first is the focus for users to be able to see their ci minutes as well as their sas runner duration usage. We've previously introduced this at the group level, but this was hidden behind a premium tier feature, and it was only for projects that were part of that group.

A

We know that this change is going to impact free users, so we're also putting this data onto the user usage quota page where ci minute usage is already being displayed.

A

This is going to let our users see what kind of impact the next set of changes might look like for them before we roll them out, and the second is to second change is to enforce a limit, albeit a very high one, on the public projects that were created prior to july 17th of 2021, which is when we put a limit in place for newly created public projects same high limit. This gets us to our next major milestone of the initiative where all public projects have some sort of high limit on them and it'll.

A

Let us turn our focus to starting to harden that limit over the coming milestones, so that we can really meet our goals of mitigating the pipeline of use.

A

So while the team is continuing to focus on this, we also have some great ux improvements coming our way, I'm going to pass the sharing over to vitica, so she can walk us through a couple of those thanks. James.

B

I would start off with uh talking a little about the issue that james already touched upon, which is providing visibility to shared in a usage at username space level.

B

So earlier we had made a decision on the uh at group level to include this information on the analytics ci cd page, but we learned that first of all, it was um not available to users from all tiers, and secondly, it was too far apart for users to be uh making a lot of sense off in comparison and kind of relating it with their uh cicd minutes uh usage, which is already sitting under usage quota page.

B

So what we did here was uh we brought the two informations together, so it would be easier to relate like how is my shared owner usage uh accounting for my shared inner minutes usage, uh sorry say: 30 minutes usage, um and this is it. This is what the design is going to look like, and we are really looking forward to this getting implemented and the other usability related issue that we worked in the previous milestone and is getting implemented in the upcoming one.

B

Is uh this one which says job ignores previous stage if cancelled and retried it's a bug, and what is the current behavior of the bug is um so when a job is restarted, it is not respecting the sequence of stages and waiting to execute only when jobs in the preceding stage have successfully completed, and we do that. That's definitely not how it should be. It should totally take into account the status of the jobs that it was depending on to start and that's what we want to make happen here.

B

So we have finally arrived a proposal for this which says solve the problem on the back end by not enqueuing the job directly and use this parameter, which looks at the whole pipeline.

B

So now, when you restart a job, uh it will take into account the status of the previous uh job that or the jobs in the previous stage, if it's being executed by the sequence of stages and there's that now I'll move on to some other ux system usability scale, impacting issues that I'm looking at uh in this milestone, so that we are able to take them up in one of the upcoming upcoming milestones.

B

The first one here says: your users cannot react. Much request to a merge strain when pipeline must succeed is enabled. So what is happening is uh when pipeline must succeed is enabled and you, as a user you're, adding a merge request to the most train and the python gets started for the most trained and accidentally you happen to remove that merge, request from the train or maybe because of um some uh fault it gets uh dropped from the train.

B

It is not possible to add it back to the train, because, uh because 500 succeed is uh like selected, so we want to change this. We want to enable user to be able to add it back to the train and not get blocked here and that's what we'll be working towards.

B

Another one says: cannot merge virgin request due to unknown requirement, so um I hope you haven't, but in case you have ever run into this situation where it says you can only merge once the items above are resolved and there's no clear indication of what is it for you to resolve.

B

um You want to look into it and we will make sure that we are communicating very clearly about what needs to be done for you to get to a healthy merch button and the last one that we want to look at is get push option merge, request. Merchant pipeline succeed does not use more strength. So when you have merged strings, enabled for your project and you use the git push option to merge uh when pipelines succeed, what it does is.

B

Instead, it does emerge immediately, which shouldn't happen, and we want to fix this bug and we're going to make sure the experience is on track and that's all from me back to you. Teams.

A

Thank you vitica. I I'm really excited that you're finding and surfacing these usability issues that aren't about the interface and really about the experience. So we don't need to change design, but we need to change how it works for users to make their workflow a lot simpler and easier. Thank you so much for finding those and servicing those to the team. They're super important for us, and I can't wait to not put a bunch of empty commits into my merch trade, mrs, so that I can get them back onto the train.

A

That'll be very exciting when we start working on implementing that. So we are very excited for the 1410 milestone. If any of these issues are interesting to you either in the implementation or the design phase feel free to give us a tag on any of them. Thanks.