The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Foster a collaborative community of developers who can easily share, build, and maintain high-quality CI/CD configurations. By providing a platform that embraces the open-source process, we aim to empower developers to focus on true innovation and unlock the full potential of the open-source ecosystem. Through our commitment to inclusivity, transparency, and accessibility, we strive to create a culture of continuous learning and improvement, where every community member can contribute.
Provide the best-in-class experience for building and maintaining CI/CD pipelines.
This section defines the terminology throughout this project. With these terms we are only identifying abstract concepts and are subject to changes as we refine the design by discovering new insights.
The component catalog will be a collection of components which:
A pipeline component is a reusable single-purpose building block that abstracts away a single pipeline configuration unit. Components are used to compose a part or entire pipeline configuration. It can optionally take input parameters and set output data to be adaptable and reusable in different pipeline contexts while encapsulating and isolating implementation details.
Components allow a pipeline to be assembled by using abstractions instead of having all the details defined in one place. Therefore, when using a component in a pipeline, a user shouldn't need to know the implementation details of the component and should only rely on the provided interface.
A pipeline component defines its type which indicates in which context of the pipeline configuration the component can be used. For example, a component of type X can only be used according to the type X use-case.
For best experience with any systems made of components, it's fundamental that components are:
Some of those best practices will be enforced in the product while others would need to be enforced by the user.
spec:input, which will allow users to define an input for any includable file, by doing so we will provide our existing users that are using CI templates an immediate value by allowing them to declare define inputs to be used with any file which is included in their pipeline.The work for the Pre-requisite for CI component epic is underway. In this phase we are going to implement some of the component elements into our existing templates solution so users could gain value and provide their feedback to help guide us in future iterations.
At the end of this epic users should be able to:
The best way to understand how GitLab works is to use it for as much of your job as possible, this is why we practice dogfooding We have recently begun collaborating with our internal productivity team to work on the CI catalog. This effort is being tracked through this collaboration issue, and the team is currently identifying commonly used CI templates and attempting to convert them into components. Our goal is to understand our customers' challenges when converting their templates into components.
Notable competitors in this space are:
Watch this walkthrough video of the different contribution frameworks available by these competitors:
Q1 - Why are you not using templates?
variables: that affects the entire pipeline leading to inheritance issues. Users should be able to convert their existing templates to CI components.Q2 - Why aren't you using variables?