Story (Required)

As a <Konflux User> trying to <build a component that uses multiple private git submodules> I want <to grant token access to all submodules using a glob pattern>

This story aims to simplify the process of granting Pipelines as Code (PaC) access to private git submodules. Currently, users must manually list every single submodule repository, which is inefficient and requires admin intervention for each addition. By supporting wildcards/glob patterns, users can authorize access to all repositories within a GitHub organization (e.g., "my-org/*") in a single configuration step, greatly improving the user experience for teams managing many submodules.

Background (Required)

Users building components from repositories that contain private git submodules face build failures because the PaC-generated GitHub App token is scoped only to the main repository. The current workaround involves onboarding each submodule as a Konflux component and having an admin manually add the submodule's repository name to the `spec.settings.github_app_token_scope_repos` list in the main repository's `Repository` CR.

This process is cumbersome, error-prone, and creates a bottleneck by requiring admin intervention for every new submodule. An initial proposal to have PaC automatically parse the `.gitmodules` file was considered but ultimately rejected due to the high implementation complexity and security risks.

The agreed-upon path forward is to enhance the `github_app_token_scope_repos` setting to accept glob patterns. This provides a pragmatic and secure solution that addresses the user's needs without a major refactor of security-sensitive code. For example, a user could specify `"ansible-automation-platform/*"` to grant access to all current and future submodules within that GitHub organization.

Out of scope

• Automatically detecting submodule repositories by parsing the `.gitmodules` file.
• Supporting submodules located on a different git provider (e.g., main repo on GitHub, submodule on GitLab) via this mechanism.
• Any UI changes in the Konflux frontend to manage this setting. This is a backend-only change to the Custom Resource Definition (CRD).

Approach (Required)

• Modify the Pipelines as Code (PaC) controller to update how it processes the `Repository` CR.
• Extend the logic for the `spec.settings.github_app_token_scope_repos` field to recognize and expand glob patterns.
• When PaC requests a scoped token from the GitHub App, it will expand any glob patterns (e.g., `my-org/*`) into a full list of matching repository names that the GitHub App has been installed on.
• This ensures the temporary token generated for the pipeline run has the necessary permissions to clone the main repository and all submodules matching the pattern.

Dependencies

• None. This is a self-contained feature within the Pipelines as Code component.

Acceptance Criteria (Mandatory)

• GIVEN a `Repository` CR is configured with a glob pattern (e.g., `spec.settings.github_app_token_scope_repos: ["ansible-automation-platform/*"]`).
• AND a pipeline is triggered for the main repository.
• WHEN the pipeline attempts to clone the repository and its submodules (`git clone --recurse-submodules`).
• THEN the clone operation must succeed for the main repository and all private submodules located in the `ansible-automation-platform` GitHub organization.

  ---

• GIVEN a `Repository` CR is configured with a mix of explicit repository names and glob patterns.
• WHEN a pipeline is triggered.
• THEN PaC must correctly resolve all repositories and generate a token with the appropriate scope.

  ---

• GIVEN an invalid glob pattern is provided in the `Repository` CR.
• WHEN the CR is applied.
• THEN the system should handle it gracefully, preferably with a validation error on the resource status.

  ---

• GIVEN a glob pattern matches repositories where the Konflux GitHub App is not installed.
• WHEN a token is requested.
• THEN PaC should not fail and should request permissions only for the repositories where the app is installed.