GitLab GitLab Group Kickoffs - Verify:Pipeline Execution (formerly known as CI), 11 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 14.3 Kickoff - Verify:Pipeline Execution

Description

Welcome to Verify Pipeline Execution14.3 Kick Off! This group is responsible for GitLab CI, such as pipelines, pipeline processing, as well the category of Merge Trains. In 14.3 we are exclusively focused on reliability and SaaS availability. Veethika will also dive into some priorities on her plate for the usability of GitLab CI.

https://gitlab.com/gitlab-org/ci-cd/pipeline-execution/-/issues/69

A

Welcome to the verify pipeline execution, 14.3 kickoff, my name is jackie porter acting product manager for the pe group here at gitlab. As a reminder, this group is responsible for the entire gitlab ci experience such as pipelines, pipelines processing, as well as the category of merge trains, I'm joined by the pe product designer vitica and in 14.3. We're really experienced on the get lab hosted first theme in fiscal year: 22, which means we're really dedicated to reliability and sas availability.

A

Vitica will also be diving into some of her priorities around the usability of gitlab ci. First up is one of the issues that she'll be discussing.

B

Great, thank you so much chucky. um So in 14.3 we are once again focusing our attention on improving the usability of various areas within ci, and this is the first issue in the lineup, so blog manual jobs does not indicate. Blockage is due to protected environment. What this is about is um when there's a manual job in a pipeline which is deploying to a protected environment, then the empty state that we present to users.

B

It does not have a trigger to run the job from that screen itself, so we'll make sure that users do not have to leave this page just to be able to run that manual. Action.

B

The next one is uh deleting pipeline bills from the ui. It's very meta like uh so currently. Pipeline builds cannot be deleted from the ui, and this is a very frustrating experience and especially for users who had auto devops enabled by default, and the only way they could get rid of those uh pipeline builds is via api. So we'll make sure that they would be able to do this from the somewhere from the ui.

B

Another one is um simplifying our world strategies uh with just auto merge, so in gitlab ci we offer a range of combinations for word strategies and, from top of my mind, a few things that I can think that of that we can configure our um to merging pipeline, succeeds, enabling mergesol pipeline merge, train, etc. Now, as these strategies have evolved over time, the language in which we communicate it to our users, it has gotten really complicated and we realize that so this will be our effort to simplify our communication around the strategies to our users.

A

I'm really excited about these investments. These experiences will really help our users in the future. Thank you. So much for going through these design priorities and as mentioned in 14.3, our development priorities are all about reliability. So we have a few infradev issues. Planned infradev is a label. We use to indicate that an issue is tied to gitlab.com performance and reliability.

A

The first one that we plan to tackle is around stock ci jobs, workers, timing out this means that it's not working as expected and it times out causing some major priority uh problems. So we intend to deliver this in 14.3. The second issue that we expect to deliver in 14.3 is around archiving a build log. That's not fully transactional.

A

This is a production database issue around build logs and it's a build trace, artifact issue that we're also expecting to have a major impact on gitlab.com, and it will improve the resiliency of trace support once we fix this issue for the archive trace crown. Worker physica is also working on some interesting work related to supporting mac os minutes in gitlab.com, which I will let her cover.

B

Sure um our current proposal for mac osci minutes is to track and build our usage as a separate line item than the current default generic ci minutes. But we do not support viewing these quotas as a separate item on the ui. So with this proposal uh in this issue we would add a feature in the ui that displays to customer the usage and remaining minutes for mac os a separate line item from generic ci minutes.

A

This is going to be such a great investment for our apple developers and mac os team, which the runner team is currently developing.

A

A second interesting investment that we are going to be making in 14.3 on the development side is around sharding blockers. uh The sharding team, which is the database team uh on the enablement group, uh is working on expanding some of our database tables, and these sharding blockers are really around uh helping our ci builds table. So this will help enable get lab ci performance, so we're going to be delivering git labs ci commit status for project paths, which is another kind of technical debt, sharding blocker issue, in addition to fixing another project scope issue.

A

Hopefully these two issues will add some headroom for the sharding team and really enable the skit lab ci performance in 14.3. We're really excited for the 14.3 release, both because of our design priorities and our development priorities. I'm pretty sure this is going to be the best release ever.