GitLab 12.6 Release Kickoff, 18 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 12.6 Kickoff - Verify: Continuous Integration

Description

GitLab 12.6 kickoff video for Continuous Integration product category in the Verify stage.

We welcome your feedback on GitLab.com and you can contact me directly at tyeager@gitlab.com or mention me on an issue.

Child/parent pipelines (#16094) · Issues · GitLab.org / GitLab · GitLab
https://gitlab.com/gitlab-org/gitlab/issues/16094

Support CI job definition outside repository (external `.gitlab-ci.yml`) (#14376) · Issues · GitLab.org / GitLab · GitLab
https://gitlab.com/gitlab-org/gitlab/issues/14376

Cross-project build artifacts dependencies (#14311) · Issues · GitLab.org / GitLab · GitLab
https://gitlab.com/gitlab-org/gitlab/issues/14311

Ability to set rules for triggering pipeline in entirety (#29654) · Issues · GitLab.org / GitLab · GitLab
https://gitlab.com/gitlab-org/gitlab/issues/29654

Ability to set rules for triggering pipeline in entirety (#29654) · Issues · GitLab.org / GitLab · GitLab
https://gitlab.com/gitlab-org/gitlab/issues/29654

Trigger pipeline when another project is rebuilt (#9045) · Issues · GitLab.org / GitLab · GitLab
https://gitlab.com/gitlab-org/gitlab/issues/9045

A

Hello, everyone, my name, is Talia here and I- am the product manager for verify continuous integration at gate, lab I'd like to share with you what we plan to deliver in the 12.6 milestone, scheduled to release on December, 22nd they're, essentially, six features that I will highlight for the 12.6 milestone. One is of particular interest to the community with a significant number of upvotes and then the remaining our continuation of feature development already in progress. I'll start with the new feature and then I'll give a brief recap of the five carryover features start.

A

First, we'll start with the significant feature we'll be working on in 12.6 to support child-parent pipelines. This feature will help to address some of the problems that have emerged with complex pipelines. Some key pain points listed there under the problems to solve specifically slowness due to arbitrary weights for jobs.

A

To start until steps are in preceding stages, are completed, and then configurations are difficult to understand as a result of being lengthy and convoluted due to a comprehensive single global pipelines and then also you have the inability to trigger sub pipelines when the gamal can be generated. Dynamically, so many of these problems can be addressed by allowing the original or parent pipeline to trigger child pipelines to run concurrently.

A

Some of the benefits we hope to gain or are listed under proposal, a few of which are that we expect performance can be improved as child pipelines execute their jobs, entirely independent of the unrelated jobs and other child pipelines, and then configurations can be easier to understand once decentralized and reduce to manageable sizes within each child's respective pipeline configuration this feature is an MVC and will have limitations that we plan to address and follow-up issues before your awareness.

A

Some of the limitations are that only one level of child pipelines will be allowed in a parent-child mapping of one to many, and child pipeline's will not be able to trigger further downstream pipelines. This is a really citing feature and it will solve for many problems inherent with complex pipelines, and we hope that, knowing that this is coming will give you something to celebrate next one of the work that we are continuing from the previous milestone.

A

One of the features is the ability to define ACI llamo outside a projects repository there's many use cases served by allowing the path of the CI a configuration to point to an arbitrary URL external to the project. For example, the CI configuration can live in a central repository and serve hundreds of other projects that need to be processed within the same way. This Lex ability will also help users to migrate from Jenkins to skit lab CI, if they're, currently using the Jenkins plugin to serve the same purpose.

A

We're also continuing the work to enable reusing job artifacts from the last successful build of a specific stage from another project. So if you have a pipeline with a dependency on artifacts from another project, this will allow you to configure the fetching of those artifacts more efficiently and it eliminates the other methods for achieving the same results such as using curl to an end point to find the latest artifact.

A

Where are, we are currently finishing up the work to trigger the pipeline of a project when another project is rebuilt as an Enterprise Edition feature. This allows you to set a project to automatically trigger itself based on successful, builds of the master branch of another project and we're excited to deliver this feature as an MVC.

A

Next is the item that we've been working on for a while, and this is now in review and being finalized. It's the ability to set rules for triggering a pipeline in its entirety at a global setting, and this top-level setting is evaluated independent of rules at the job level.

A

This is a powerful way to determine when a pipeline should run without having to add the same rule to every job in the pipeline, as you would currently be necessary to do in order to discreetly achieve the same outcome and then, finally, we have an issue that was previously blocked and will likely resume implementation to allow defining an empty needs array to specify a job has no predecessor the significant of the this is it effectively sets the job to start immediately, regardless of the stage in which the job belongs to the pipeline.

A

That's it for the upcoming 12.6 release. If you have any questions or suggestions, we welcome your comments in the issues or you can contact me directly. We'd love to hear from you thanks and have a great day.