When enabled, every commit status update looks up the commit's merge request pipeline and explicitly targets it via pipeline_id, instead of letting GitLab decide based on the commit SHA, ref and status name alone.

Without this, GitLab treats (sha, ref, status name) as an identity: the first status update for a build either attaches to whatever pipeline already exists at that moment, or spins up a throwaway "external" pipeline if none does yet - and every later update for the same build keeps updating that same entry in place, even after GitLab's own merge request pipeline for the commit is created. That can leave a build's final result invisible to anything that only looks at the merge request's head pipeline, such as "pipelines must succeed" merge checks.

If no merge request pipeline exists yet for the commit (e.g. a plain branch build with no open merge request), this has no effect and GitLab's default behavior is used.

This is off by default to preserve existing behavior. It applies wherever the per-step or per-job attachStatusToMergeRequestPipeline setting is unset, e.g. a gitlabCommitStatus, updateGitlabCommitStatus or gitlabBuilds Pipeline step call that omits that argument. Saving a job's configuration form always stores an explicit per-job value, which then takes precedence.