Plan: support trusted-provider-hostnames for Pipelines as Code (no code changes yet)

[Copilot]

Changes

No code changes are in this PR yet. It is a plan only, pending approval, for supporting PAC's trusted-provider-hostnames setting and learned-host annotation. The setting comes from tektoncd/pipelines-as-code#2871.

This is based on reading the operator code and the issue. I could not read the PAC PR from my sandbox, so I don't yet know which PAC release contains it.

• Settings round-trip
  • setPACDefaults and updateAdditionControllerConfigMap both go through pacSettings.SyncConfig and ConvertPacStructToConfigMap.
  • go.mod vendors PAC v0.49.0, which has no trusted-provider-hostnames field, so the key would be dropped.
  • Bumping the dependency should fix this with little or no operator code. ConvertPacStructToConfigMap already handles string fields.
  • components.yaml already says v0.51.0, so the two versions need reconciling.
• Additional-controller RBAC
  • Additional controllers have no update or patch on their own ConfigMaps.
  • Proposed fix: per enabled controller, add a Role and RoleBinding to its CustomSet installer set. The Role would grant get, update and patch on configmaps with resourceNames: [<ConfigMapName>], bound to the pipelines-as-code-controller ServiceAccount.
  • Skip the Role when the controller shares the primary pipelines-as-code ConfigMap.
• Annotation preservation
  • I'd check the ConfigMap transformer and the installer-set re-apply path for anything that drops pipelinesascode.tekton.dev/auto-trusted-provider-hostnames.
  • Verification would be a unit test with a pre-annotated ConfigMap.
• Dependency and manifest bump
  • Run go get, ./hack/update-deps.sh, update components.yaml, and run hack/fetch-releases.sh.
  • The bump may add other new settings fields and change test fixtures.
• Tests, one per acceptance criterion
  • Defaulting and transform tests for settings retention.
  • A golden test for the Role and RoleBinding scope.
  • An annotation-preservation test.
  • Docs updates in docs/OpenShiftPipelinesAsCode.md and docs/TektonConfig.md.
• Not verifiable without a live cluster
  • That the controller can actually patch its ConfigMap through the Role and RoleBinding.
  • That the annotation survives an installer-set re-apply on a live API server.
  • Behaviour when upgrading an existing install that has additional controllers.

Open questions

• Which PAC release contains Bump github.com/spf13/cobra from 1.9.1 to 1.10.1 #2871?
• Should get be in the Role, or only update and patch?
• Which ServiceAccount should the RoleBinding target?
• Does the setting need to be Kubernetes-aware, or is it OpenShift-only?

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Run make test lint before submitting a PR
• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide for more details.

Release Notes

NONE

• Fixes Support trusted provider hostnames for Pipelines as Code #3946

[linux-foundation-easycla]

• ❌ - login: @Copilot / name: copilot-swe-agent[bot]. The commit (0868e1e, e410f99) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please visit our EasyCLA portal and chat with our support bot.

[jkhelil]

@copilot Please proceed with implementation based on the plan, with the following answers to your open questions:

1. PAC release containing feat: pin GitHub host on first authenticated webhook pipelines-as-code#2871: [check and fill in the tag/version — e.g. v0.51.0]
   May be wait for bump(deps): bump github.com/openshift-pipelines/pipelines-as-code version to v0.51.0 #4183 landing
2. RBAC verbs: grant get, update and patch (get is needed so the controller can read-modify-write the ConfigMap safely).
3. RoleBinding target: pipelines-as-code-controller ServiceAccount, same as you proposed.
4. Scope: Both — the setting lives in PACSettings.Settings (shared by TektonConfig, OpenShiftPipelinesAsCode, and Kubernetes TektonConfig). Additional controller RBAC is needed on both platforms wherever additional controllers are enabled.
   Go ahead and implement per the plan. Keep the PR in draft until all acceptance criteria are checked off and the submitter checklist (make test lint, tests, docs) is complete.

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from jkhelil after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment