Currently, Pipelines for merge requests use branch ref (e.g. refs/heads/feature) to create a pipeline. This pipeline works nicely and it's displayed on merge requests, however, we should use merge request HEAD refs (e.g. refs/merge-requests/:iid/head) in order to tightly couple the git reference with a corresponding merge request.
Basically, the expected results from job execution perspective is exactly the same with using branch pipelines, because merge request head refs point to the same SHA with branch ref.
This is a breaking change, but very important step for our final goal Use combined merge refs with merge request pipelines. We'll eventually have to use merge request merge ref (e.g. refs/merge-requests/:iid/merge). We should implement the fundamental components at this step in order for reducing the change size of the final MR.
By using merge request refs (regardless of head or merge), we'll lose backward compatibility because there are two requirements for running pipelines successfully:
refspecs feature)If 1. is missing, detached merge request pipelines fail because it cannot checkout source code properly. In order to switch back to the old behavior, we add a feature flag (ci_use_merge_request_ref). We can easily fall back to the old behavior by running Feature.disable(:ci_use_merge_request_ref).
If a user submitted a merge request from a forked project, then it automatically uses legacy detached merge request pipelines. This is the current behavior that runs a job on branch ref.
Expected:
refs/merge-requests/:iid/head) and succeedsExpected:
refs/heads/branch-name) and succeedsExpected:
ci_use_merge_request_ref feature flag is disabledExpected:
refs/heads/branch-name) and succeedsExpected:
refs/heads/branch-name) and succeedsRelated: https://gitlab.com/gitlab-org/gitlab-ee/issues/7380
Close: https://gitlab.com/gitlab-org/gitlab-ce/issues/58454