Defining your pipelines is an important part of Continuous Integration, and we want to make it as easy as possible.
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:
.gitlab-ci.yml that make it easier and more natural to set up complicated, flexible pipelines. In the past, it's been challenging or over-verbose to express complex pipeline definitions. Good examples of this are our new simpler syntax for expressing complex rules, the needs keyword for building direct dependency relationships (as a Directed Acyclic Graph), the matrix keyword which allows for creating many similar copies of a job, and using technologies like jsonnet or dhall, with good examples/templates, to allow for code-based generation of the YAML.Beyond this, there are some interesting opportunities we've just begun to explore:
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.
Our new (dynamic) child/parent pipelines feature is getting some attention with three major MVCs in progress:
.gitlab-ci.ymlSince 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.
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.
Pipeline Authoring is not independently analyzed as an analyst category. See our Continuous Integration Direction for this content.
To be determined
Our top customer issues (search) include the following:
needs: (DAG) to refer to a job in the same stageOur top internal customer issues (search) include the following:
needs: (DAG) to refer to a job in the same stagewhen:manual within triggered pipelinesOur top dogfooding issues (search) are:
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.
