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.
| Stage | verify |
| Maturity | Minimal |
| Content Last Reviewed | 2023-06-04 |
Thanks for visiting this direction page on the Components catalog category at GitLab. This page belongs to the Pipeline Authoring Group in the Verify Stage and is maintained by Dov Hershkovitch. You can submit your feature requests using GitLab issue tracker.
We aim to foster a collaborative community of developers who can easily share, build, and maintain high-quality CI/CD configurations. By providing a platform that serves as a centralized hub for managing all DevOps-related assets within an organization, 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 continuous learning and improvement culture where every community member can contribute.
DevOps is all about speed, it delivers value faster by shortening the software development life cycle. Organizations that want to accelerate their DevOps adoption need to set up a working pipeline so other teams can use it to automate their workflow. During the development of a pipeline configuration, engineers frequently encounter the following challenges:
While it is possible to solve each problem separately, GitLab believes that we need to solve those problems holistically by building a framework that contains tools that add functionality and improve your CI/CD workflow. We aspire to provide the best-in-class experience for building and maintaining CI/CD pipelines.
Our strategy is to provide an opinionated framework that:
We should adopt a bottom-up approach to construct this solution, starting with the smallest building blocks and gradually progressing upwards. By starting from the foundational elements and gradually building on them, we can create a robust and cohesive solution.
| Track | Status | Feature | Details |
|---|---|---|---|
| 1 | Completed | Deliver input interpolation as Beta |
Allow users to construct a reusable pipeline configuration. |
| 2 | Completed | Deliver experimental CI/CD components | A component is the smallest building block in a catalog. |
| 3 | Completed | Release experimental CI/CD Components Catalog - index page | Single page listing all available components in an organization. |
| 4 | In dev | Restructure components | Restructure components to accommodate an existing customer structure. |
| 5 | Completed | Release experimental CI/CD Components Catalog - details page | Detailed view of a component. |
| 6 | In dev | Input interpolation improvements | Input enhancements. |
| 7 | Planning breakdown | Make inputs/interpolation a GA feature | |
| 8 | Planning breakdown | Introduce steps |
A step is a script that the runner runs. |
| 9 | In dev | Make CI/CD catalog/components Beta. |
Improved release workflow, improved Catalog UX, and stable directory structure. |
| 10 | Planning breakdown | Visibility of Components usage | Provide an analytics dashboard for component usage. |
| 11 | Not started | Create an instance-wide catalog | Could evolve to become the Community catalog. |
Upcoming dates can be found here.
In addition, you can watch this short video, which explains the remaining before transitioning the Catalog from Experimental to Beta
Over the next milestones, we will be focusing on answering the top three problems mentioned above:
In addition, we'll continue the discussion with internal teams as they dogfood some of our popular CI/CD template to component
16.5 Planning issue can be found here in the upcoming milestone, we are going to focus on:
Support variables ininputs: - which will help us transition inputs from Beta to GA
Below is a tentative timeline proposal that outlines on a per milestone basis the committments by the Pipeline Authoring and Runner teams to CI Steps. The CI Steps epic can be found here.
| Milestone | Release date | Projects (aka theme) priority 1 |
|---|---|---|
16.9 |
2024-02-15 | CI Steps - Experimental |
17.1 |
2024-05-21 | CI Steps - Beta |
17.5 |
2024-09-18 | CI Steps - GA |
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
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 these internal teams in GitLab which expressed their desire to dogfood some of our features:
Notable competitors in this space are:
Watch this walkthrough video of the different contribution frameworks available by these competitors:
This section defines the terminology used throughout this project. With these terms we are only identifying abstract concepts, and they are subject to changes as we refine the design by discovering new insights:
The component catalog will be a collection of components. This collection:
When on Premium+ plan, each top-level namespace has access to a namespace catalog. This lists all catalog resources that are hosted directly or indirectly under the given namespace. A namespace catalog does not contain resources hosted under other top-level namespaces.
It's a searchable list of all released components repositories in a namespace. A GitLab instance can have many namespace catalogs. In the future, potentially could become "Organization CI/CD Catalogs" (especially useful for SaaS).
An instance catalog is available on GitLab instances. It lists catalog resources that have "internal" or "public" access level.
This catalog allows users of a GitLab instance to see what other components outside a given Namespace Catalog are available for a project to use.
It's a searchable list of all released public/internal CI/CD components in an instance. One per instance.
On GitLab SaaS, the Instance Catalog could be renamed as the "Community Catalog", to encourage open sourcing and contribution to components.
It's the name for GitLab.com's (SaaS) Instance CI/CD Catalog, configured for public CI/CD components only (no internal projects on SaaS).
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 the best experience with any system 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.