feat(openshift): add ServiceMonitor for remote resolvers

[deekshith-24]

Changes

Adds a ServiceMonitor for the tekton-pipelines-remote-resolvers deployment on OpenShift, so its metrics (exposed on the http-metrics port) get scraped by the cluster's Prometheus, consistent with the existing monitors for the pipeline controller, webhook, triggers, chains, results, and pruner.

New file: cmd/openshift/operator/kodata/openshift-monitoring/04-pipeline-resolvers-monitoring.yaml

Verified on a live OpenShift (ROSA) cluster: the ServiceMonitor is created automatically alongside the others, with selector and port matching the live tekton-pipelines-remote-resolvers Service.

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

Add a ServiceMonitor for tekton-pipelines-remote-resolvers metrics on OpenShift.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: deekshith-24 / name: Deekshith Kumar Netha Bamandla N (1021aad)

[jkhelil]

Code Review

Thanks for adding coverage for the remote resolvers — this fills the last observability gap in the pipeline component family.

The YAML itself is structurally correct (selector, port name, namespace selector, annotations all check out against the live manifests). However there is a critical mTLS wiring gap that will cause scraping to silently break on any cluster where the operator has enabled metrics mTLS.

---

🔴 Critical — ServiceMonitor not wired into the mTLS upgrade path

The project has a full mTLS-for-metrics subsystem in pkg/reconciler/openshift/tektonpipeline/extension.go. When metricsMTLSReady is true the reconciler already applies the full mTLS treatment to the resolvers (lines 102–114):

occommon.AnnotateMetricsServingCert(tektonRemoteResolversControllerName),
occommon.RenameServicePort(tektonRemoteResolversControllerName,
    occommon.MetricsHTTPPort, occommon.MetricsHTTPSPort),  // http-metrics -> https-metrics
occommon.ApplyMetricsTLS("Deployment", tektonRemoteResolversControllerName, ...),
occommon.ApplyMetricsTLS("StatefulSet", tektonRemoteResolversControllerName, ...),

So when mTLS is active:

• The Service port is renamed http-metrics to https-metrics
• The pod serves TLS and requires a client certificate from Prometheus

But filterAndTransformMonitoring() (lines 261–296) upgrades five ServiceMonitors for mTLS and the new openshift-pipelines-resolvers-monitor is absent from that list. The ServiceMonitor will keep requesting port: http-metrics — a port that no longer exists on the Service — and Prometheus scraping will fail.

Fix — add one entry to filterAndTransformMonitoring() in extension.go, matching the exact pattern used for the other monitors:

occommon.UpdateServiceMonitorForMetricsMTLS(
    "openshift-pipelines-resolvers-monitor",
    occommon.MetricsHTTPPort, occommon.MetricsHTTPSPort,
    tektonRemoteResolversControllerName, targetNS),

This is the same call made for openshift-pipelines-monitor, openshift-triggers-monitor, openshift-chains-monitor, openshift-pruner-monitor, and openshift-results-watcher-monitor. Without it the new monitor works only on clusters that have not yet enabled mTLS.

---

Minor suggestions

• scheme: http baseline: 03-pipeline-webhook-monitoring.yaml explicitly sets scheme: http on its endpoint. Adding it here makes it auditable what the plain-HTTP baseline is before the mTLS transformer upgrades it.
• honorLabels: true: The controller (00-monitoring.yaml) and results-watcher (05-results-monitoring.yaml) monitors both set this. Worth considering for consistency if the resolvers emit a job label on their metrics.

---

What's good

• Selector label app: tekton-pipelines-remote-resolvers and port http-metrics both verified against cmd/openshift/operator/kodata/tekton-pipeline/1.15.0/00-pipelines.yaml.
• namespaceSelector: openshift-pipelines is correct — injectNamespaceConditional moves all resources (including the resolvers Service) to the target namespace at reconcile time.
• Naming, annotations, and YAML structure are consistent with all other monitors in the set.

The YAML file just needs the companion extension.go change to be complete.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 26.13%. Comparing base (142b069) to head (d850bf8).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3920      +/-   ##
==========================================
- Coverage   26.14%   26.13%   -0.01%     
==========================================
  Files         465      465              
  Lines       24940    24944       +4     
==========================================
  Hits         6520     6520              
- Misses      17698    17702       +4     
  Partials      722      722              

Flag	Coverage Δ
unit-tests	26.13% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[khrm]

/lgtm

[deekshith-24]

/retest

[jkhelil]

/retest

[jkhelil]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jkhelil

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [jkhelil]

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