You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As Helm has now supported OCI for a few years, the old helm repo add mechanism has become less used and represents more steps to do for the end user. Also users have reported issues with our current nightlies host, see #812.
I propose the following for our two helm charts:
Get a public OCI location under the apache namespace
Publish the current chart versions to OCI, plus the still-supported older releases so users can pin and upgrade
Update the release process to publish new charts to both HTTPS and OCI
Announce to users that the classic HTTPS chart repo is deprecated
Publish to OCI only from v1.0.0 onwards, and stop updating the HTTPS chart repo
On where to publish: GHCR is a better fit than Docker Hub. Docker Hub only supports a single namespace level, and helm push takes the chart name from Chart.yaml, so on Docker Hub the charts can only land as apache/solr and apache/solr-operator. That spends the apache/solr name on a chart rather than leaving it for a Solr server image, and mixes chart tags and image tags in the same repo. GHCR supports nested paths, so the charts can be namespaced away from the image names while still being named solr and solr-operator. Public GHCR packages are anonymously pullable, and publishing from CI needs no new secrets. Docker Hub stays available as a second location later if we want it.
One caveat either way: GHCR creates new packages as private, and there is no API to change that, so an INFRA ticket is needed once per chart name to make the package public.
I put up a PR as a draft. It uses a manually triggered github workflow for the last publishing step, as the committer then does not need to manage docker hub secrets. Have a look
It is rebased on current main and switched from Docker Hub to GHCR, publishing to oci://ghcr.io/apache/solr-operator/helm/{solr,solr-operator}. Cross-publishing to both the OCI registry and the HTTPS repo continues through the 0.x releases, with v1.0.0 being the first OCI-only release.
I verified the mechanics on my own namespace first: nested paths work, a public package is anonymously pullable with no helm registry login, and a 2-level parent coexists with its nested children — so nesting the charts under solr-operator/ does not consume ghcr.io/apache/solr-operator for a future operator image.
Review welcome, particularly on the path layout, since the INFRA action to make a package public is one-time per chart name and awkward to redo.
Activity
janhoy commentedon Jan 20, 2026
I put up a PR as a draft. It uses a manually triggered github workflow for the last publishing step, as the committer then does not need to manage docker hub secrets. Have a look
janhoy commentedon Sep 3, 2026
There is an updated PR available for this: #814.
It is rebased on current
mainand switched from Docker Hub to GHCR, publishing tooci://ghcr.io/apache/solr-operator/helm/{solr,solr-operator}. Cross-publishing to both the OCI registry and the HTTPS repo continues through the 0.x releases, withv1.0.0being the first OCI-only release.I verified the mechanics on my own namespace first: nested paths work, a public package is anonymously pullable with no
helm registry login, and a 2-level parent coexists with its nested children — so nesting the charts undersolr-operator/does not consumeghcr.io/apache/solr-operatorfor a future operator image.Review welcome, particularly on the path layout, since the INFRA action to make a package public is one-time per chart name and awkward to redo.