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 | Viable |
| Content Last Reviewed | 2024-11-25 |
Thanks for visiting this category direction page on Merge Trains in GitLab. This page belongs to the Pipeline Execution group of the Verify stage and is maintained by Rutvik Shah (E-Mail).
This direction page is a work in progress, and everyone can contribute:
We aim to help you balance speed with reliability, keeping your pipelines green. This ultimately supports the stability of collaboration across branches and GitLab has introduced Merge Trains as the mechanism to accomplish this. When merge trains are used, each merge request joins as the last item in that train. Each merge request is processed in order and is added to the merge result of the last successful merge request. The merge request adds its changes, and starts the pipeline immediately under the assumption that everything is going to pass. If the merge request fails, it is kicked out of the train and the next merge request continues the pipeline of the last successful merge result.
For an overview of our plans for Merge Trains, see epic Merge Trains Vision and check out this overview video:
Our top vision item is to improve Merge Train usability by providing users better visibility into system status, therefore, increasing their confidence in the workflow. Beyond that we want to provide Developers and DevOps Engineers a better way to visualize and administer the merge train.
In FY25Q4 (Nov-Jan 2025), we will continue to make usability improvements
We will be making the following usability improvements
We recently released an MVC to visualize merge train
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.
This category is currently at the "Viable" maturity level, and our next maturity target is "Complete" (see our definitions of maturity levels. We currently have basic capabilities and want to continue and extend these in future milestones.
Key deliverables to achieve this are:
It looks like GitLab is the first to provide this functionality, although GitHub has annouced a public beta for Merge Queue which includes fast-forward merge train support and visualizations of the queue.
Aviator is the most comparable offering against Merge Trains, promising to "keep builds green forever", much like how we positioned Merge Trains in 2020 during their release. Today, Merge Queues seem to support parity of Merge Trains for GitHub repositories.
marge-bot is a popular open source program that works with GitLab to manage merge requests.
Mergify is another offering that integrates with GitHub repositories and multiple CI providers to supporty queued pull requests.
Check out our Ops Section Direction "Who's is it for?" for an in depth look at the our target personas across Ops. For Merge Trains, our "What's Next & Why" are targeting the following personas, as ranked by priority for support:
In an effort to dogfood our own features, we are actively working on using merge trains internally on gitlab-org.