feat: adding metric configuration and services for cas and controlplane

[lemonprogis]

Hey y'all 👋

In our deployments of Chainloop OSS, we have created a couple of services in a config chart to expose the metrics endpoints to be scraped by prometheus via a servicemonitor.

I did a couple of simplifications compared to the http and grpc services. Keeping this one ClusterIP only etc.

It's configurable similarly to the others using the same conventions. This allows prometheus to lookup the endpoints of the pods and scrape every pod as the replicasets scale.

[cubic-dev-ai]

No issues found across 4 files

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

[migmartri]

Code review

A few concerns about consistency with the rest of the chart:

1. Shared top-level metrics: breaks the per-component convention

Every other component setting lives under controlplane.* or cas.* (e.g., controlplane.service, cas.serviceAPI, controlplane.containerPorts.metrics). Even the dex sub-chart uses dex.metrics.enabled. A single global metrics.enabled means you can't enable metrics for one component independently. The convention would be controlplane.metrics.* / cas.metrics.*.

chainloop/deployment/chainloop/values.yaml

Lines 54 to 65 in 05478c1

	## @section Prometheus Metrics
	## @extra metrics Prometheus metrics configuration for controlplane and CAS
	## @param metrics.enabled Enable metrics services for both controlplane and CAS
	metrics:
	enabled: false
	## @extra metrics.service Metrics service configuration
	service:
	## @param metrics.service.port Metrics service port
	port: 5000
	## @param metrics.service.annotations Additional custom annotations for metrics services
	annotations: {}

2. Duplicate port default

metrics.service.port: 5000 introduces a new independent value, but controlplane.containerPorts.metrics: 5000 and cas.containerPorts.metrics: 5000 already exist. If someone changes containerPorts.metrics, the service port won't follow. The templates should reference the existing per-component values instead of introducing a duplicate.

3. Dead $podLabels variable in controlplane template

$podLabels is computed but never used — the selector uses chainloop.controlplane.selectorLabels instead. The CAS counterpart correctly omits this line.

chainloop/deployment/chainloop/templates/controlplane/service-metrics.yaml

Lines 23 to 25 in 05478c1

	protocol: TCP
	{{- $podLabels := include "common.tplvalues.merge" (dict "values" (list .Values.controlplane.podLabels .Values.commonLabels) "context" .) | fromYaml }}
	selector: {{ include "chainloop.controlplane.selectorLabels" . | nindent 4 }}

-- Miguel

[migmartri]

also make sure to run sign off the commits, thanks!

[lemonprogis]

Thank you @migmartri for the review! Address the comment above, also adding sign-off as well. What's funny is I had it per one before but thought it made sense as a top level since it's shared :D

[cubic-dev-ai]

1 issue found across 3 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="deployment/chainloop/templates/controlplane/service-metrics.yaml">

<violation number="1" location="deployment/chainloop/templates/controlplane/service-metrics.yaml:6">
P2: Configuration path changed from `metrics.enabled` to `controlplane.metrics.enabled` without backward-compatibility handling. Existing deployments using the old path will silently have metrics disabled. Consider adding backward compatibility (e.g., `{{- if or .Values.controlplane.metrics.enabled .Values.metrics.enabled }}`) or documenting the migration requirement.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: Configuration path changed from metrics.enabled to controlplane.metrics.enabled without backward-compatibility handling. Existing deployments using the old path will silently have metrics disabled. Consider adding backward compatibility (e.g., {{- if or .Values.controlplane.metrics.enabled .Values.metrics.enabled }}) or documenting the migration requirement.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At deployment/chainloop/templates/controlplane/service-metrics.yaml, line 6:

<comment>Configuration path changed from `metrics.enabled` to `controlplane.metrics.enabled` without backward-compatibility handling. Existing deployments using the old path will silently have metrics disabled. Consider adding backward compatibility (e.g., `{{- if or .Values.controlplane.metrics.enabled .Values.metrics.enabled }}`) or documenting the migration requirement.</comment>

<file context>
@@ -3,24 +3,23 @@ Copyright Chainloop, Inc. All Rights Reserved.
 */}}
 
-{{- if .Values.metrics.enabled }}
+{{- if .Values.controlplane.metrics.enabled }}
 apiVersion: v1
 kind: Service
</file context>

Suggested change

	{{- if .Values.controlplane.metrics.enabled }}
	{{- if or .Values.controlplane.metrics.enabled .Values.metrics.enabled }}

[lemonprogis]

Issue ref: #2900