Story (Required)

As a Developer trying to run CI pipelines for a Pull Request from a private fork I want Pipelines-as-Code to automatically extend the installation token to include the fork so that the pipeline can clone the source code without manual configuration of the Repository CR.

Currently, for private-to-private repository workflows, PaC requires the upstream Repository CR to explicitly list every trusted fork in the spec.settings.github_app_token_scope_repos field. This creates a manual bottleneck. We want to automate this: if the GitHub App is already installed on the fork's organization/account, PaC should dynamically include that fork in the token scope.

Background (Required)

When a PR is created from a private fork, the default token generated for the upstream repo does not have visibility into the fork. This results in git-clone failures (e.g., remote: Repository not found).

The technical goal is to leverage the existing GitHub App installation. If a user has installed the App on their fork, PaC has the authority to request a token that spans both the base and head repositories. By automating this in the PaC controller, we remove the need for maintainers to manually "allow-list" every contributor's fork in the CR.

Out of scope

• Workflows where the GitHub App is NOT installed on the fork (this will still require the manual allow-list or will fail).
• Automating the installation of the GitHub App on the user's personal GitHub account.
• Support for other git providers (this story is specific to the GitHub App flow).

Approach (Required)

_ _Webhook Logic Enhancement:* Modify the PaC controller to extract the head repository information from the incoming pull_request webhook.
_ _Dynamic Scoping:* Instead of relying solely on the static list in spec.settings.github_app_token_scope_repos, the controller should verify if the installation ID for the upstream also covers the fork.
_ _Token Request:* Update the token generation logic to request a scope that includes both the base.repo.full_name and head.repo.full_name dynamically.
_ _Condition Check:* If the fork is private and the App is installed, the token should be extended. If the App is not installed on the fork, fall back to existing behavior (check the manual allow-list in the CR).

Dependencies

_ _GitHub API:* Requires the GitHub App to be installed on both the upstream and the fork for the same App ID.
_ _Pipelines-as-Code Controller:* Direct modification of the event processing and token generation modules.

Acceptance Criteria (Mandatory)

• When a PR is submitted from a private fork (with the App installed), PaC successfully generates a token covering both repos.
• The git-clone task can successfully clone the private fork using the PaC-provided token.
• The Repository CR in the upstream namespace does NOT require the fork repo to be listed in github_app_token_scope_repos for the clone to succeed.
• If the GitHub App is not installed on the fork, the pipeline fails gracefully with a clear message indicating the App is missing on the source repository.
• Unit tests covering the dynamic token scope generation for PullRequest events.