Expose both pipeline_ref and source_ref for pipelines webhook events
Context
We noticed in https://gitlab.com/gitlab-org/quality/engineering-productivity/triage-ops-playground/-/merge_requests/17#note_2098489782 something odd with the pipeline webhook events. It seems that the ref attribute is the ref value from the merge request instead of the pipeline.
It is inconsistent with the Pipelines API, which will return the pipeline_ref in the ref attribute.
It was apparently done on purpose in gitlab-foss!28772 (merged). This comment explains it best:
This is a similar fix with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27663. In some places, we use
reffor showing a generic branch name, such asuse-source-ref-name-in-webhook, and in the other places, we usereffor getting data ofci_pipelines.ref, which could be a generic branch name OR full ref path, such asrefs/merge-requests/:iid/head.For the pipeline webhook payload, users do not care the full ref path as well as they don't care in
CI_COMMIT_REF_NAMEpredefined variable. Thus, we can just change therefvalue to bepipeline.source_ref.
As for this part of the comment:
For the pipeline webhook payload, users do not care the full ref path as well as they don't care in
CI_COMMIT_REF_NAMEpredefined variable.
This isn't true as far as Engineering Productivity is concerned, because we use the full ref from the pipeline webhook event to determine whether the pipeline is a merged results pipeline.
Goal
Expose both the pipeline_ref and the source_ref in the pipeline webhook event, so that people can choose to use either.