feat(helm): support global.imageRegistry/global.image.registry

[okhowang]

Note

Low Risk
Low risk: a small Helm templating change that only affects how container image names are constructed when optional registry values are set.

Overview
Adds support for overriding the container image registry in the Pyroscope Helm chart via either a new global.imageRegistry value (applies across the chart) or pyroscope.image.registry (per-chart).

Updates the deployment/statefulset template to prefix images with the chosen registry, and documents/threads the new values through values.yaml and generated jsonnet/values.json.

^{Written by Cursor Bugbot for commit ef56d98. This will update automatically on new commits. Configure here.}

[CLAassistant]

All committers have signed the CLA.

[simonswine]

Not quite sure if this can/should also impact the sub charts that we have:

pyroscope/operations/pyroscope/helm/pyroscope/Chart.yaml

Lines 10 to 23 in e7cc2ff

	alias: agent
	version: "0.44.2"
	repository: https://grafana.github.io/helm-charts
	condition: agent.enabled
	- name: alloy
	alias: alloy
	version: "1.5.2"
	repository: https://grafana.github.io/helm-charts
	condition: alloy.enabled
	- name: minio
	alias: minio
	version: 4.1.0
	repository: https://charts.min.io/
	condition: minio.enabled

Note: This would also change the default image to be with docker.io, don't think this is risky.

[marcsanmi]

I think this would be a breaking change for users who have a full registry in image.repository today, e.g.:

myregistry.com/grafana/pyroscope:tag → docker.io/myregistry.com/grafana/pyroscope:tag

Could you default image.registry to empty instead of docker.io, and only prepend the registry when explicitly set? Something like:

{{- $registry := .Values.global.imageRegistry | default $values.image.registry -}}
image: "{{ if $registry }}{{ $registry }}/{{ end }}{{ $values.image.repository }}:{{ $values.image.tag | default .Chart.AppVersion }}"

This way existing users with repository: myregistry.com/grafana/pyroscope aren't broken, while the new global.imageRegistry / image.registry feature still works.

[marcsanmi]

Thanks for addressing my earlier feedback @okhowang

To address @simonswine's comment about sub-charts: could you rename global.imageRegistry → global.image.registry? The Grafana sub-charts (alloy, grafana-agent) already read global.image.registry, so Helm will propagate it automatically.

Also, CI needs the generated files updated — please run make helm/docs && make lint and commit the results.

[okhowang]

I read both global.imageRegistry and global.image.registry now.
because I notice that loki support them both. grafana/loki#19246

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue.}

[marcsanmi]

Thanks for the updates. As you might have noticed, there isn't a consistent standard across Grafana charts for the global image registry key:

• global.imageRegistry — used by Grafana, Loki, Tempo (single-binary)
• global.image.registry — used by Alloy, Grafana Agent, Tempo-distributed

Loki ended up supporting both with global.imageRegistry taking precedence and global.image.registry as a deprecated fallback. This PR follows that same approach.

@simonswine — should we support both keys like Loki does (which is what this PR currently implements), or pick just
one? Worth noting that global.image.registry automatically propagates to our alloy/grafana-agent sub-charts since they already read that key, while global.imageRegistry does not.

[marcsanmi]

For reference, the Bitnami common library only uses global.imageRegistry and doesn't support global.image.registry.

Given there's no consistent standard across Grafana charts either, maybe I'd lean toward following Bitnami's convention and only supporting global.imageRegistry — simpler, no deprecated fallback to maintain. The trade-off is that it won't
automatically propagate to our sub-charts (alloy/grafana-agent use global.image.registry)

[simonswine]

Given there's no consistent standard across Grafana charts either, maybe I'd lean toward following Bitnami's convention and only supporting global.imageRegistry

Agree with that, I have also done a github code search for either and it is about 44k matches for global.imageRegistry vs. 4k global.image.registry.

[marcsanmi]

@okhowang I think you need to run make helm/check to make the CI happy.

[marcsanmi]

LGTM, thanks for addressing all the changes.