Issues–merge requests relationship for Value Stream Management
For Value Stream Management (VSM), we are using labels to define the various stages of the value stream: gitlab-ee#6323
For the VSM flow, we assume that you start with an issue, then develop in an MR, and finally do deployments to different environments. We want to change labels in issues as they progress through the VS, including deployment of its corresponding code.
However, there are a couple of outstanding challenges with MRs as noted in gitlab-ee#6323:
An issue can be related to a merge request. When the merge request's code moves throughout these deployment environments, the corresponding labels are added to or removed from the associated issue linked to the merge request.
Additionally, if given issue has multiple linked merge requests, all those merge requests need to reach a certain CI stage before the associated one issue advances in the board.
Currently, an issue can be related to many merge requests, and the coupling is not very tight. We need to build a feature to refine this further. In particular, you should be able to de-link a merge request form an issue.
Expanding on these:
- Issues can have multiple related merge requests but can only be closed once, by one MR.
- Issues can even be closed by merge commits: #25163
- MRs can be related to multiple issues and can close multiple issues. (Example: #17500 (closed))
- MRs can live without an issue. We should support “orphan” MRs.
- Both issues and MRs support labels. Would users update the labels in the issue, its related MRs, or even in the multiple issues that an MR closes? There's the risk of users updating in the “wrong” place.