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.
Defining your pipelines is an essential step to getting started with Continuous Integration. In the Ops Section direction this is the gateway to enable "Operations for All", where our goal is to make the authoring experience as easy as possible for both novice and advanced users alike. We believe that creating a green pipeline quickly and easily will help development teams leverage our CI to increase their efficiency. One of the ways we measure success is by improving the % of first green pipelines.
As a practitioner of Speedy, Reliable Pipelines, GitLab wants your time to a green pipeline to be the fastest on any platform.
When you're setting up something new, and especially when learning a new CI platform, there can be a lot to take in, and it can be hard to even know what you don't know, and what kinds of options and strategies are available to you. This is why our focus over the next three years is to create an amazing authoring experience in a way that leads to getting your first green pipeline as quickly as possible while leveraging all the available features and functionalities GitLab CI can offer.
Support you as the author of a pipeline with providing powerful autocomplete capabilities by generating our own JSON schema, which can be contributed upstream and used by any external editor (VScode, sublime text, etc…)
We know that creating a complex pipeline will require iteration and several rounds of trial and error, this is why we want to provide you with the ability to test your pipeline in different scenarios such as MR pipelines, branches and variables before they run on your environment, this way you can prevent failure and shorten the feedback loop.
Check out our Ops Section Direction "Who's 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:
If you have any feedback on our 3 year vision which you would like to share please do so in the Pipeline authoring 3 year vision
For more general information on CI direction see also the general Continuous Integration category direction. You may also be looking for one of the following related product direction pages: GitLab Runner, Continuous Delivery, Release stage, or Jenkins Importer.
The planning for version 14.5 is undergoing, you can view and contribute directly to the planning issue
We are currently working to mature the Pipeline authoring category from viable to complete. Definitions of these maturity levels can be found on GitLab's Maturity page. The following epics group the functionality we have planned to mature pipeline authoring.
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: (DAG) 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
Our top customer issues (search) include the following:
Our top internal customer issues (search) include the following:
Our top dogfooding issues (search) are:
Pipeline Authoring is not independently analyzed as an analyst category. See our Continuous Integration Direction for this content.
