Support trusted provider hostnames for Pipelines as Code

Open
#3,946 1 comment 1 reaction 2 assignees View on GitHub

Maintainers usually reply within 1 day

@jkhelil is already working on this.

Since Oct 2, 2026.

  • #4196 by @copilot-swe-agent — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
50/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go, kubernetes

Research direction

Start after tektoncd/pipelines-as-code#2871 is released, then inspect the vendored Settings conversion and reconciliation paths for primary and additional controllers. Review the bundled manifests and additional-controller RBAC resources, and add coverage for settings retention, scoped ConfigMap permissions, and annotation preservation. Done means the acceptance criteria pass and TektonConfig, OpenShiftPipelinesAsCode, and upgrade behavior are documented.

Written by the indexing model from the issue text.

Description

area/dependency kind/feature

Problem

Pipelines as Code PR tektoncd/pipelines-as-code#2871 introduces an administrator-owned trusted-provider-hostnames setting and allows each controller to record authenticated, publicly routable self-hosted providers in the pipelinesascode.tekton.dev/auto-trusted-provider-hostnames ConfigMap annotation.

This operator work should begin after that PAC PR is merged and the change is available in a PAC release.

The operator rebuilds PAC ConfigMap data through PAC's vendored Settings type and creates additional PAC controllers from a filtered copy of the primary manifest. Updating only the PAC images/manifests would leave two integration gaps:

  • An operator version using an older PAC Settings type cannot round-trip trusted-provider-hostnames through the OpenShiftPipelinesAsCode or TektonConfig settings.
  • Additional controllers use their own ConfigMaps but do not currently receive scoped update/patch permission for those ConfigMaps, so they cannot record learned hostnames.

Proposed work

  • After tektoncd/pipelines-as-code#2871 merges, bump the PAC dependency and bundled release manifests to a release containing it.
  • Ensure trusted-provider-hostnames is accepted and preserved in the primary and additional controller settings maps.
  • Give every enabled additional controller scoped update and patch access to its own ConfigMap. Prefer a Role and RoleBinding owned with that additional controller's resources.
  • Verify operator reconciliation preserves the controller-owned pipelinesascode.tekton.dev/auto-trusted-provider-hostnames annotation.
  • Document configuration through TektonConfig and OpenShiftPipelinesAsCode, including the upgrade requirement for self-hosted providers using per-repository or incoming webhooks.

Example primary-controller configuration:

spec:
  platforms:
    openshift:
      pipelinesAsCode:
        settings:
          trusted-provider-hostnames: "ghe.example.com,gitlab.example.com"

Acceptance criteria

  • The PAC dependency and manifests contain tektoncd/pipelines-as-code#2871.
  • Primary and additional controller settings retain trusted-provider-hostnames after defaulting and reconciliation.
  • Each additional controller can patch only its configured ConfigMap for learned-host annotation updates.
  • Operator reconciliation does not remove the learned-host annotation.
  • Tests cover settings conversion, additional-controller RBAC, and annotation preservation.
  • Operator documentation explains configuration and upgrade behavior.
Dominant language
Go
Stars
606
Forks
270
Avg merge
1d 7h
Merged PRs (30d)
159

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tektoncd/operator

All issues in tektoncd/operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.