Story (Required)

As a developer using a forked repository workflow in GitLab,
I want to see the PipelineRun status directly on the target project's Merge Request,
So that I can quickly assess the state of my changes without navigating to my source fork.

This improves the user experience by centralizing all relevant Merge Request (MR) information, including CI/CD status, in one place. Currently, Pipelines as Code (PAC) posts the commit status to the source fork, which is not where developers and reviewers typically look. This change will make the workflow more intuitive and efficient.

Background (Required)

Currently, when a PipelineRun is triggered from a GitLab Merge Request originating from a fork, PAC reports the commit status back to the source project (the fork). The desired behavior is to report this status on the target project, where the MR is being reviewed.

There was an initial concern that this might not be possible due to the commit SHA not being available on the target project before the merge, or potential token permission issues. However, this was disproven via a proof-of-concept script, confirming that the GitLab API allows setting a commit status on the target project using a project-scoped token, even when the commit originates from a fork.

This change is requested to align PAC's behavior with developer expectations and streamline the MR review process.

Relevant Slack Discussion: https://redhat-internal.slack.com/archives/C04PZ7H0VA8/p1758291314955519
Related Jira: KFLUXSPRT-5172

Out of scope

• This change only applies to the GitLab provider. Other SCM providers are not affected.
• The behavior for non-Merge Request events (e.g., direct pushes to a branch) will remain unchanged. The status will continue to be reported on the project where the event originated.

Approach (Required)

The implementation will involve modifying the `SetCommitStatus` function in the GitLab provider (`pkg/provider/gitlab/status.go`).

1. Add conditional logic to detect if the incoming event is for a Merge Request.
2. If the event is a Merge Request, extract the `TargetProjectID` from the event payload.
3. Use this `TargetProjectID` instead of the source `Project.ID` when making the GitLab API call to set the commit status.
4. If the event is not a Merge Request, the existing logic of using the source `Project.ID` will be used.

Dependencies

• Possibly related to work in this PR: https://github.com/openshift-pipelines/pipelines-as-code/pull/2231

Acceptance Criteria (Mandatory)

• AC1: GIVEN a PipelineRun is triggered by a Merge Request from a forked repository, WHEN PAC reports the commit status, THEN the status appears on the target project for the Merge Request.
• AC2: GIVEN a PipelineRun is triggered by a direct push to a branch (not associated with an MR), WHEN PAC reports the commit status, THEN the status appears on the project where the push occurred (the existing behavior).
• AC3: The functionality is verified to work with the standard project-scoped tokens used by PAC in Konflux, confirming there are no permission issues.

INVEST Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Legend

Unknown
Verified
Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met