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 Updated | 2025-05-26 |
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:
For December to February 2025, we have the following items planned for the CI Automation category:
Currently the team is focusing on providing a solution for one of our main customer request
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.
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:
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: