Allow a single repository to trigger PipelineRuns in multiple namespaces on the same cluster

[singha200]

Feature request

PAC currently enforces a one-to-one mapping between a Repository CRD and a namespace. This prevents users from using a single repository to trigger pipelines across multiple namespaces (e.g., different environments) on the same cluster.
This would be a significant quality-of-life improvement for teams managing multi-environment workflows on a single OpenShift cluster using PAC.

Use case

In a typical multi-environment setup on a single cluster, a team may have:

my-app repo
├── triggers pipeline in → namespace: my-app-dev
├── triggers pipeline in → namespace: my-app-staging

Currently this is not possible because PAC only allows one Repository CRD per repository per cluster. Creating multiple Repository CRDs pointing to the same repo in different namespaces is not supported.

Desired Behavior

Allow a single repository to target multiple namespaces, so that:

A push to main could trigger a PipelineRun in my-app-prod
A push to dev could trigger a PipelineRun in my-app-dev
Each namespace can have its own secrets, service accounts, and resource quotas

Current Behavior

Only one Repository CRD is allowed per repository per cluster. Users cannot target different namespaces from the same repository, making multi-environment pipelines on a single cluster impossible with PAC alone.

[chmouel]

Currently, this isn't supported and would require a pretty massive refactor to pull off. The design works this way because, in a multi-user Kubernetes environment (ie: common on OpenShift for example), we don't have a reliable way to verify that a repo actually belongs to a specific cluster user. Right now, we rely on a 'first-come, first-served' model where the person who creates the repo is considered the owner.

If we allowed multiple repos per namespace, we’d lose that layer of trust. It becomes a security risk because we wouldn't know which user actually owns the CI, especially in clusters with private repositories and untrusted users. As a workaround, you can use the target-namespace annotation on a PipelineRun, though that does mean you have to explicitly name the namespace in the resource. This is the same method we use to keep our functional tests self-contained.

[singha200]

Thanks for the explanation.
We looked into the target-namespace annotation workaround, but it still requires the Repository CRD in the originating namespace and also needs the PAC mutating webhook to be disabled, which requires cluster-admin access that end users don't have.
So unfortunately the workaround isn't practical for our use case.
We've filed the issue to track this as a feature request.