GitLab GitLab Group Kickoffs - Verify:Pipeline Execution (formerly known as CI), 12 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 15.3 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:

- Reduced cost factor for forks of public projects - https://gitlab.com/gitlab-org/gitlab/-/issues/346400
- Lower cost factor for OSS plans - https://gitlab.com/gitlab-org/gitlab/-/issues/351933
- UI for rebase without pipelines - https://gitlab.com/gitlab-org/gitlab/-/issues/118825
- Performance Insights button - https://gitlab.com/gitlab-org/gitlab/-/issues/363512/
- MVC: Configure CI/CD Quotas by project - https://gitlab.com/gitlab-org/gitlab/-/issues/357760
- Category maturity plan for CI Scaling - https://about.gitlab.com/direction/verify/continuous_integration_scaling/
- Add indication that a job was processed by a decommissioned Runner - https://gitlab.com/gitlab-org/gitlab/-/issues/29947

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, 15-3 kickoff, my name is james heimbach, product manager for the pipeline execution group here at giblet. As a reminder, this group is responsible for gitlab ci pipelines, pipeline processing, as well as the category of restraints I'm joined today by the pipeline execution product designer vitka.

A

You will find a link to the 15-3 kickoff page with links to these items in the verify stage direction page with discussion of our future work. In the comments below the video. You can always reach me at jheimbach, gitlab.com or through comments on items with the group pipeline execution label in the gitlab project or any of the issues we're going to talk about today.

A

So I'm already sharing uh my screen with our 15-3 planning issue, and we have a number of things that we want to talk about today.

A

I'm going to start by saying during the 15-3 milestones, the themes for our group or the theme for our group is to make the experience of running pipelines great for open source contributors, and that's that being our main goal is to support that along with then our ongoing goal of meeting our reliability, slos or the slos for a reliability related issues. Those are always signified with a verified p1.

A

You see, we have a lot of those in this milestone, but we are keeping up with the the issue slo and providing a more stable, reliable and performant platform for the users on gitlab.com, so with our first goal of providing that great experience for open source program projects and their contributors when they're running pipelines, there's a couple issues that I wanted to dig into and talk about a little bit. The first is this one of using the reduced cost factor for public forks.

A

This is an issue that has been moving around a little bit milestone milestone, but it is something that we will get unblocked to be delivering in 153. We believe, and that will then use a reduced amount of ci cd minutes when you're contributing with a public fork to one of those public projects or oss projects.

A

Another part of that is number 351933, setting a lower cost factor for the oss plans. If you've read the right documentation, you know that we use cost factor to adjust and so there's a difference between the actual runner minutes that are being consumed and how those applied to cicd minutes and what is applied to your account every month. We're going to be lowering the cost factor so that members of the oss program actually have more minutes.

A

That'll help kind of give them a little bit more of a bridge over as all of the public projects now are accumulating minutes, just as they adjust and make changes to their ci setup and the last one here is one that we're actually going to be supporting a community contributor.

A

But I wanted to call it out because kev is such a great community contributor and it's such a great improvement for users and that's one one. Eight eight two five uh providing the ui within the merge request to rebase without having to run a pipeline. So this should save significant time of not having to run the pipeline and save significant ci cd minutes of not having to run a pipeline every time to rebase, especially if the project that you're trying to contribute to is rapidly changing.

A

So this will be a better experience for those contributors to rapidly changing open source programs.

A

And then the last issue that I want to call out is an experiment that the team is going to run we're actually working on it in 15-2. You can see the milestone it didn't get pulled into the milestone before our last kickoff, which is why I wanted to call it out today and we think we'll deliver it within 15.3.

A

um So what we're going to do is introduce a performance insight button uh in a modal window to the pipeline details, page and I'll click into the design. Real, quick here we're going to run this experiment for two milestones and then we're going to turn the feature off.

A

But we would love to hear your feedback for it and see if this is something that we should continue or if this is a feature that there's no interest in uh and so within the interface itself, there will be a link into an issue uh where you can leave us feedback and there's a feedback issue linked here as well within the issue.

A

uh So we hope that you get a chance to experience that uh use that performance insights, button, look at the data, that's presented there to you and let us know what you think is this helpful. uh Is this something that you want to see us continue to pursue, um or is it something that's not very useful in its current in incarnation, and with that I'll hand it over to vitica to discuss some of the in upcoming usability improvements, the team is exploring from later this year and some research that should be working on.

B

Thank you so much james. I have so much like really high hopes from the experiment that we are running and I'm really looking forward to the feedback that would receive for that from that um yeah and 15.3 is going to be research heavy for the pipeline execution, ux team, which is me and uh we'll be focusing on a couple of research uh items this milestone, and so here the one that you're looking at. We worked on the designs for this issue in the ongoing milestone, which, uh and what uh like?

B

What is this all about, so this particular proposal would allow users to set a limit for the usage, consumption or resources in the projects they own to avoid running out of resources. So it would let you like set a limit for um the cicd minutes by project, but currently we are only focusing on uh allowing this to happen from the uh for the user, namespaces and eventually we'll get to groups subgroups and all of that.

B

But so we have uh like put together a design proposal. um It's all set to be implemented in 15.6, but in the meanwhile, what we want to do is we want to validate some of the decisions that we have made. Some of the assumptions that we had while creating these proposals, so we might be reaching out to some of you uh to recruit you for the research, so keep an eye out for that and now moving on to the next one, so category direction for continuous integration scaling yeah.

B

I I uh wanted to talk about uh this one, because we are planning on uh doing a category maturity scorecard research for this particular category, and we want to see if this is ready to be moved from minimal to viable. Now. What does viable stand for survival means that um okay uh just a moment, I think I lost that somewhere.

B

Yeah significant use at gitlab uh like within the company, and uh we might be recruiting like internal uh users only, but that really depends on what plan we come up with and yeah. Looking forward to see like how far we have come with this particular category.

B

And lastly, there's this one issue that I would be looking at in this milestone uh and this talks about that if a runner is deleted and all the jobs that were processed by it uh they're no longer uh they no longer display which runner process them in the sidebar like where you get to see the details for all the runners, so it doesn't appear there now there is a way to figure out uh that, like so what you can do is uh you can look at the first eight characters of the runner registration token from the job trees to any of their existing specific uh or group runners.

B

But of course that's I mean it's not even easier said. It's really difficult to do that, so we want to come up with a proposal so that users could easily identify if the job has been run by a decommissioned runner, and that is all from me back to you. James thanks.

A

Vedica, if someone's interested in giving you some feedback or some feedback, especially around the cscd quota, uh can they leave a comment on the issue and tag you and I would that be the best method.

B

Yeah definitely, I would love to hear some feedback on this.

A

Fantastic, so yeah get in there and leave some comments on the design. We'd love to hear from you, so we're so excited for 53.. uh If any of these issues are of interest to, you feel free to tag us um and the in on the issues uh that are being implemented or the issues that are being designed thanks so much.