Story (Required)

As an authorized maintainer trying to trigger a CI pipeline for a Merge Request submitted by a user who doesn't have direct CI execution permissions, I want the /ok-to-test command to successfully start the pipeline immediately, so that I don't have to instruct the original author to re-commit and force push, streamlining the contribution process for external contributors.

Background (Required)

Currently, when an unauthorized user submits a Merge Request (MR), and an authorized user comments /ok-to-test, the CI pipeline fails to start with the error message: "There was an issue validating the commit: "could not find any PipelineRun in your .tekton/ directory"". The only current workaround is for the original, unauthorized author to perform a `git commit --amend` and `push --force` on their branch, after which the /ok-to-test command works as expected. This behavior is unexpected, as /ok-to-test is intended to allow authorized individuals to override initial permission checks and explicitly trigger CI runs.

Out of scope

• Changing the underlying security model that prevents unauthorized users from directly triggering pipelines.
• Granting direct pipeline execution permissions to all MR authors.
• This story does not cover other commands or general CI system behavior beyond the /ok-to-test command interaction with unauthorized MR authors.

Approach (Required)

The issue seems to stem from the CI system's inability to process or find the `.tekton/` directory within the MR's head commit when the initial push is from an unauthorized user, even after an authorized user issues /ok-to-test. The proposed approach involves:

1. Investigate the /ok-to-test command handler: Understand why the validation for `.tekton/` directory fails specifically in this scenario. It's likely related to the context or permissions under which the validation is performed.
2. Ensure authorized context: When an authorized user issues /ok-to-test, the subsequent pipeline validation and execution process should leverage the permissions/context of the authorized user who issued the command, rather than relying solely on the original MR author's permissions for file discovery.
3. Rethink `.tekton` discovery: Ensure that the CI system can successfully locate and interpret the `.tekton/` directory from the MR's head commit when /ok-to-test is triggered, regardless of the original committer's authorization status, as long as the command itself is issued by an authorized entity.
4. Error Handling: Improve error messages if the `.tekton/` directory is genuinely missing or malformed, to distinguish from permission-related access issues.

Dependencies

• Specific CI system components related to /ok-to-test command processing.
• GitLab (or similar Git hosting service) integration components.
• Tekton (or similar pipeline execution engine).

Acceptance Criteria (Mandatory)

• GIVEN an unauthorized user (e.g., an external contributor) creates a Merge Request (MR) containing a valid `.tekton/` directory.
• WHEN an authorized user (e.g., a maintainer) comments /ok-to-test on that MR.
• THEN a CI pipeline is successfully triggered for the MR.
• AND the pipeline starts without encountering the "could not find any PipelineRun in your .tekton/ directory" error.
• AND the unauthorized author of the MR is not required to `git commit --amend` and `push --force` to enable the pipeline to run.
• GIVEN an authorized user creates an MR with a valid `.tekton/` directory.
• WHEN the authorized user comments /ok-to-test on their own MR.
• THEN a CI pipeline is successfully triggered (ensuring no regression).

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