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 | 2024-08-25 |
| Content Last Updated | 2024-10-07 |
Thanks for visiting this category direction page on Pipeline Composition in GitLab. This page belongs to the Pipeline Authoring group of the Verify stage and is maintained by Dov Hershkovitch (E-Mail).
This direction page is a work in progress, and everyone can contribute:
GitLab CI is the platform that you use to ship your software to your customers as fast as possible. As outlined in our 3 year strategy, we want to enable platform teams to share operational definitions (infrastructure, environments, deployment pipelines, monitoring configuration) with development teams, and for development teams to easily contribute improvements. The Developer Automation category is the backbone to eliminating the user friction for authoring those pipeline configurations throughout the GitLab CI/CD journey.
Pipeline Composition is born from the need to solve how nearly 80% of a developer's time is spent on non-coding tasks, as shown in GitLab's 2024 Global DevSecOps Report. Eliminating the hurdles to authoring, editing, and updating of pipeline configuration by using "smarter" syntax or autocomplete features empowers our users to leverage GitLab's end-to-end DevSecOps platform more fully. Broadly, this category aims to deliver excellence in the following problem areas over the next three-years:
September to February 2025:
March 2025 to May 2025:
June 2025 to August 2025:
For October to December 2024, we have the following items planned for the CI Automation category:
In 17.6, the Pipeline Composition Category is continuing work toward the CI Steps Minimal Maturity plan, in addition, will aim to complete:
rules:changes:compare_to now supports CI/CD variablesrules:exists CI/CD keywordneeds or rulesBIC (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.
Our main competitor doing innovative things in terms of pipeline authoring is GitHub, who have evolved Actions into more and more of a standalone CI/CD solution. GitLab remains far ahead in a lot of areas of CI/CD that they are going to have to catch up on, but Microsoft and GitHub have a lot of resources and have a large user base excited to use their product, especially when given away as part of a package. Actions has a more event-driven and community plugin-based approach than GitLab, whereas we take community contributions directly into the product where they can be maintained.
GitHub actions are a seemingly powerful toolkit with a high potential for low maintainability with community contributions as we have seen with Jenkins. We are monitoring to swiftly incorporate the best of their innovation into our product. We've already had some successes running GitHub Actions directly in GitLab CI and will continue to explore that. We are also working on a migration guide to help teams we're hearing from who are looking to move over to GitLab have an easier time. Features like making the script section in containers optional would make it easier to build reusable plugins within GitLab that would behave more like Actions and Allow needs: to refer to a job in the same stage to enable users to run an entire pipline without defining stages.
A limitation of the GitHub Actions API is the exclusiveness interaction with the service via a workflow YAML checked into a repository. By contrast, GitLab enables users to define units of work to execute as a service, for example, via mutli-project pipelines, dynamic child pipelines and parent-child pipelines.
Watch this walkthrough video of Github actions
Circle CI is a Continuous Integration platform that builds a robust process for using and contributing Orbs. Circle CI Orbs are reusable snippets of code packages as YAML configuration condenses repeated pieces of config into a single line of code. Once an orb is created, it could be published to the orb registry, which becomes available to any of the Circle CI user base.
Watch this walkthrough video of the different contribution frameworks available by GitHub Marketplace, Circle CI and CodeFresh.io.
Gitea Actions implements a similar event based system like GitHub Actions for CI/CD. The infrastructure features a runner, actions orchestration subsystem, and the action definition.
Check out our CI Section Direction "Who is it for?" for an in depth look at the our target personas across Ops. For Pipeline Authoring, our "What's Next & Why" are targeting the following personas, as ranked by priority for support:
Pipeline Composition features and CI Steps are a building blocks within the GitLab CI syntax model. This feature set will be offered in GitLab Free, and will work with other complimentary capabilities such as CI/CD components, compute minutes, AI experiences, and Analytics to offer feature discovery moments for Premium, Ultimate, and Duo licensed users.
The Gartner Magic Quadrant evaluates leadership of Continuous Integration offerings within the DevOps Platforms landscape. GitLab is a leader in this space and this category aims to sustain our position in this by defending our strong hold in the following spaces:
CI Steps affords us a new technology to begin approaching and solving user needs with different use cases and problems than our install base. We can continue to support our current capabilities while also future-proofing and looking forward with more sustainable, smart solutions.
CI Steps are reusable and composable pieces of a job. These are used within the GitLab project and will be used within the Component catalog for sharing. There are a few other benefits to CI Steps: