janhoy opened a new issue, #862: URL: https://github.com/apache/solr-operator/issues/862
Follow-up to #813. Our charts are now published as OCI artifacts, but Artifact Hub still only lists them from the deprecated HTTPS repo. This issue covers the manual Artifact Hub work, which cannot be automated from this repository. ## Why this is not just an edit Today we have **one** Artifact Hub repository entry, `apache-solr`, pointing at `https://solr.apache.org/charts`. Artifact Hub reads the `index.yaml` there, finds both charts, and publishes two package pages under that one entry name: ``` https://artifacthub.io/packages/helm/apache-solr/solr-operator https://artifacthub.io/packages/helm/apache-solr/solr ``` An Artifact Hub entry backed by OCI can only point at **one chart**, because the OCI distribution spec has no way to list all references in a namespace, so there is no `index.yaml` equivalent for Artifact Hub to use as an entry point. See https://github.com/artifacthub/hub/discussions/3632. Two charts therefore need two entries, and since the entry name is part of the page URL (`artifacthub.io/packages/helm/<entry-name>/<chart-name>`) and entry names are unique, we cannot serve both OCI charts under the `apache-solr` name. Two further constraints worth knowing before we start: - Artifact Hub entry names **cannot be renamed** after creation ("No, the repository name cannot be updated once created" — their FAQ), so the names we pick are permanent. - There is **no alias or redirect** for a package page that moves. ## Transition state: four listings During the 0.x dual-publishing window we deliberately keep the old entry and add two new ones, so nothing that is currently linked breaks: | Artifact Hub page | Entry name | Source | Install shown | |---|---|---|---| | `…/helm/apache-solr/solr-operator` | `apache-solr` (existing) | `https://solr.apache.org/charts` | `helm repo add` | | `…/helm/apache-solr/solr` | `apache-solr` (existing) | `https://solr.apache.org/charts` | `helm repo add` | | `…/helm/apache-solr-operator/solr-operator` | `apache-solr-operator` (new) | `oci://ghcr.io/apache/solr-operator/helm/solr-operator` | `helm install oci://…` | | `…/helm/apache-solr-cloud/solr` | `apache-solr-cloud` (new) | `oci://ghcr.io/apache/solr-operator/helm/solr` | `helm install oci://…` | Artifact Hub generates the install command from how the entry is registered, which is why the new entries are needed to show `oci://` instructions at all. This is the same pattern Argo uses: `argo-cd` is listed under both `argo` (HTTP) and `argo-cd-oci` (OCI). ## Steps ### 1. Create the two new entries In the Artifact Hub control panel (sign in, top-right menu, under the `apache-solr` organization), add two Helm repositories: | Name | URL | |---|---| | `apache-solr-operator` | `oci://ghcr.io/apache/solr-operator/helm/solr-operator` | | `apache-solr-cloud` | `oci://ghcr.io/apache/solr-operator/helm/solr` | Leave the existing `apache-solr` entry untouched. ### 2. Restore the Verified Publisher badge The existing entry is verified because Artifact Hub finds `artifacthub-repo.yml` next to `index.yaml`. An OCI entry has no such path, so the metadata has to be pushed to the registry as an artifact under the special tag `artifacthub.io`. Without this the new pages render as unverified next to our verified ones. For each chart, take the repository ID shown in the control panel and write: ```yaml repositoryID: <uuid from the Artifact Hub control panel> owners: - name: <name> email: <email matching the Artifact Hub account> ``` then push it: ```bash oras push \ ghcr.io/apache/solr-operator/helm/solr-operator:artifacthub.io \ --config /dev/null:application/vnd.cncf.artifacthub.config.v1+yaml \ artifacthub-repo.yml:application/vnd.cncf.artifacthub.repository-metadata.layer.v1.yaml ``` Repeat for `…/helm/solr`. Documented under "OCI support" at https://artifacthub.io/docs/topics/repositories/helm-charts/. Note this is a per-chart-path artifact that lives alongside the version tags, so it is worth adding to the publish workflow rather than doing by hand. ### 3. Cross-link the two charts Both charts point at each other through the `artifacthub.io/recommendations` annotation in `Chart.yaml`, which currently targets the old `apache-solr` pages. Once the new entries exist, decide whether to repoint those at the new pages or leave them until `v1.0.0`. ### 4. At `v1.0.0`, retire the old entry When the HTTPS repo stops being updated, delete the `apache-solr` entry in the control panel. Both old page URLs then die with no redirect, so first sweep the in-repo references to them: - `docs/modules/solr-cloud/pages/solr-cloud-crd.adoc` - `docs/modules/upgrade-notes/pages/upgrade-notes.adoc` - `docs/modules/getting-started/pages/local-tutorial.adoc` - `helm/solr/README.md` - the `artifacthub.io/recommendations` annotations in both `Chart.yaml` files External links and bookmarks to `…/helm/apache-solr/solr` cannot be preserved. `…/helm/apache-solr/solr-operator` could be kept alive by repointing the existing `apache-solr` entry at the operator chart's OCI path instead of deleting it, since an entry's URL is mutable even though its name is not. Worth deciding at the time. -- 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]
