Make Merge Trains available for Merge Request Dependencies
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Merge Trains was introduced to allow multiple merge requests to be queued up using Merged Result Pipelines to speed up Continuous Integration and Continuous Deployment. Now, Merge Trains have been enabled for Merge Requests that have dependencies that exist both across projects and within the same project. You can now queue a merge request with a dependency and then upon successful merge of all dependencies, the Merge Request will be automatically merged.
Problem to solve
People who have worked with Phabricator using a ‘stacked diff’ workflow generally love it and seek it wherever they next go. (source)
GitLab currently doesn't provide an intuitive way to stack diffs through Merge Requests, offering up a queueing mechanism that can provide a stacked diff experience similar to Merge Trains with Merge Request Dependencies.
Intended users
User experience goal
Delaney, the development team lead, can review multiple merge requests and queue (stack) them up to be merged in a sequential order. This stacking can be done by making it easy to create MR dependencies on already-reviewed merges and then providing a UI to modify the order in which which the merges take place. This would be very similar to the experience of graphite.dev.
Proposal
Problems to solve.
- Allow MRs with MR Dependencies to have a button that says
Merge after all dependencies are merged - Provide users with a UI that allows users to view a list of Merge Requests across projects (could be the same as a Merge Train UI)
- Provide users with a UI that allows users to edit/add to a list of MRs across projects to order that merge request list.
- Provide users in the UI mentioned in 2 and 3 to instantiate the Merging of all of the MRs in the list.
Further details
I think this could be a first iteration in the directional needs of Phabricator users that are looking for a new home and done in a way that is native to GitLab constructs.
(source)
Permissions and Security
Documentation
Availability & Testing
Available Tier
Feature Usage Metrics
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
What is the competitive advantage or differentiation for this feature?
Links / references
This 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.