We publish helm charts in the classic format at https://nightlies.apache.org/solr/release/helm-charts/
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.
We publish helm charts in the classic format at https://nightlies.apache.org/solr/release/helm-charts/
As Helm has now supported OCI for a few years, the old
helm repo addmechanism 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:
apachenamespacev1.0.0onwards, and stop updating the HTTPS chart repoOn where to publish: GHCR is a better fit than Docker Hub. Docker Hub only supports a single namespace level, and
helm pushtakes the chart name fromChart.yaml, so on Docker Hub the charts can only land asapache/solrandapache/solr-operator. That spends theapache/solrname 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 namedsolrandsolr-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.