janhoy commented on PR #814: URL: https://github.com/apache/solr-operator/pull/814#issuecomment-5527239832
@HoustonPutman I've rebased this on main and reworked it — proposing this as the resolution to our earlier discussion about where the charts should live. You were right that Docker Hub *can* host both images and charts in one repo, with the `v` prefix separating the tag namespaces. My hesitation was that it makes listing awkward, and it means the chart takes the `apache/solr` name. Rather than argue that trade-off, GHCR sidesteps it entirely: it supports nested paths, so we get ``` oci://ghcr.io/apache/solr-operator/helm/solr-operator oci://ghcr.io/apache/solr-operator/helm/solr ``` The chart keeps its natural name `solr` (which `helm push` takes from `Chart.yaml` and we can't override anyway), while `apache/solr` stays free on both GHCR and Docker Hub for a future Solr server image, and chart tags never mix with image tags. It also means no new secrets — the built-in `GITHUB_TOKEN` is enough, where Docker Hub needs credentials in CI. I verified the mechanics against my own namespace first: nested paths work, and a public package is anonymously pullable with no `helm registry login` at all. Docker Hub remains an option later if we want it; nothing here forecloses that. On the transition, I propose we **cross-publish**: every 0.x release goes to both the OCI registry and `https://solr.apache.org/charts`, so nobody has to change anything on a patch upgrade. **`v1.0.0` is then the first OCI-only release** — a major version is the natural place to drop the old channel, and it gives users a clear, version-anchored deadline rather than a date that slips with the release schedule. That's what the upgrade notes and both chart READMEs now say. When we get to 1.0.0 we'd drop `publish_helm_charts`/`upload_helm.sh` and move the Artifact Hub entries over; I've deliberately left Artifact Hub alone for now, since migrating it would change all the existing `artifacthub.io/packages/helm/apache-solr/...` URLs. One thing needing INFRA either way: ghcr.io creates new packages as **private**, and there's genuinely no self-service path — `.asf.yaml` has no packages feature, selfserve.apache.org doesn't cover it, and there isn't even a REST endpoint for it. So we'd need a ticket to flip the two packages public. It's a one-time action per chart name, and `ghcr.io/apache/airflow/...` is existing precedent that INFRA does this. Does the GHCR path layout look right to you, and are you happy with 1.0.0 as the cutover? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
