What is the reasoning behind pipelines for Draft MR not running on Merge Results ?
From the documentation about Merge Resultes:
When the merge request can’t be merged, the pipeline runs against the source branch only. For example, when: * The target branch has changes that conflict with the changes in the source branch. * The merge request is a [work in progress](https://docs.gitlab.com/13.1/ee/user/project/merge_requests/work_in_progress_merge_requests.html). In these cases, the pipeline runs as a [pipeline for merge requests](https://docs.gitlab.com/13.1/ee/ci/merge_request_pipelines/index.html) and is labeled as `detached` . If these cases no longer exist, new pipelines will again run against the merged results.
I get it that if a MR has merge conflicts, it is not possible to create a merge commit and run a pipeline on the merge results. But why excluding “Draft” MR from this feature ?
In my case, Draft MR are created because we push “fixup” commits to the source branch. It is useful that the branch is prevented to be merged by the “Draft” flag, but it’s inconvenient that the pipeline are not running on the Merge Results. We usually end up with more or less this workflow:
- Initial creation of a MR (pipeline runs on Merge Results)
- pushing fixup following review (pipeline is “detached”)
- final rebase after review is finished, squashing the fixup commits
- Usually developers forgot to remove the Draft state, so the pipeline runs in detached
- Manual removal of the Draft state and re run of the pipeline (this time on Merge results)
- Potential discovery of new issues brought by the fixup commits
I find this quite inconvenient and would prefer to get pipeline running on Merge results event when the MR is flagged as Draft. So what’s the reasoning speaking against it ?
Thanks for considering my question