Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Pipeline Authoring

Pipeline Authoring

Defining your pipelines is an important part of Continuous Integration, and we want to make it as easy as possible.

Three Year Vision

Our focus over the next three years is on improving the authoring experience in a way that leads to getting your first green pipeline as quickly as possible. 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 also one of our first key performance indicators

Our immediate priorities are:

Beyond this, there are some interesting opportunities we've just begun to explore:

Additional Resources

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.

What's Next & Why

Our new (dynamic) child/parent pipelines feature is getting some attention with three major MVCs in progress:

Maturity Plan

Since this category is already at the "Lovable" maturity level (see our definitions of maturity levels), it is important to us that we defend that position in the market. As such, we are balancing prioritization of important P2 issues and items from our backlog of popular smaller feature requests in addition to delivering new features that move the vision forward. If you feel there are any gaps or items that would risk making authoring pipelines in GitLab no longer lovable for you, please let us know.

Competitive 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.

Time will tell if distributed CI ends up being more powerful, or just harder to reason about, and if they are able to avoid the same trap of unmaintained community Actions that companies became dependent on that Jenkins ran into. Regardless, we're monitoring and bringing 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.

Analyst Landscape

Pipeline Authoring is not independently analyzed as an analyst category. See our Continuous Integration Direction for this content.

Top Customer Success/Sales Issue(s)

To be determined

Top Customer Issue(s)

Our top customer issues (search) include the following:

Top Internal Customer Issue(s)

Our top internal customer issues (search) include the following:

Our top dogfooding issues (search) are:

Top Vision Item(s)

With the beta release of the Directed Acyclic Graph (DAG) pipeline visualization, we are now collecting feedback in gitlab#220368 for the next iteration of this feature for making it easier to trace the relationship between dependent jobs. We have a set of other follow ups as well for the DAG gitlab-org#1716, which will allow for out of order execution and open a world of new possibilities around how pipelines are constructed.

We have an epic to improve the rules syntax at gitlab-org#2783, as well as one for making improvements to the CI Linter to provide more helpful warnings and links to documentation. Making it easier to use CI with external repositories is also on the radar. We also have an epic focused on improving the .gitlab-ci.yml authoring experience in a number of ways, which is related to another epic specifically focused on improving editing the .gitlab-ci.yml from within the Web IDE.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license