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.
needs: (DAG) to refer to a stageCheck 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
The work in the current milestone has been scoped, is underway. The assigned issues listed on our Pipeline Authoring planning issue. Our team's focus is outlined in the Goals for the milestone section for the current milestone, in this milestone our focus is:
include:include:The best way to understand how GitLab works is to use it for as much of your job as possible, this is why we practice dogfooding We have recently begun collaborating with our internal productivity team to work on the CI catalog. This effort is being tracked through this collaboration issue, and the team is currently identifying commonly used CI templates and attempting to convert them into components. Our goal is to understand our customers' challenges when converting their templates into components.
The planning for next versions are underway and you can view and contribute directly to the planning issues.
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
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.
Our top customer issues (search) include the following:
Our top internal customer issues (search) include the following:
Pipeline Authoring is not independently analyzed as an analyst category. See our Continuous Integration Direction for this content.