Publish the federation chart to JFrog as an OCI Helm repository

[fupelaqu]

Publish the softclient4es-federation chart to JFrog Artifactory as an OCI Helm registry, so operators can install a versioned, immutable chart instead of cloning this repo.

Current state

The chart has no publish path at all. .github/workflows/federation-helm.yml is validate-only (it triggers on pull_request and push to branches: ['!main'], and there is no tag/release trigger and no packaging step). Every documented install therefore goes through a git checkout:

helm install fed ./softclient4es-federation            # README.md
helm install fed ./softclient4es-federation -f my-values.yaml

Consequences: no immutable versioned artifact, helm upgrade has no --version to pin, operators must clone a repo to deploy, and the chart SemVer in Chart.yaml (version: 0.3.2) is currently just a label — nothing consumes it. Merging to main is the de-facto "release".

Note: Story 16.5 deliberately removed the JFrog credentials from this repo's CI ("JFROG creds and setup-java/setup-sbt removed") because a chart-only repo had nothing to publish. This issue reverses that specific decision for the chart artifact itself — the images stay on public DockerHub and are unaffected.

Proposed

Add a release workflow that packages and pushes the chart to a JFrog OCI repository:

helm registry login softnetwork.jfrog.io -u "$JFROG_USER" -p "$JFROG_PASSWORD"
helm package softclient4es-federation                 # -> softclient4es-federation-<version>.tgz
helm push softclient4es-federation-<version>.tgz oci://softnetwork.jfrog.io/<helm-repo>

Operators then install without cloning:

helm install fed oci://softnetwork.jfrog.io/<helm-repo>/softclient4es-federation --version 0.3.2

Requires an OCI-enabled (Docker-type) Artifactory repository — the existing releases / snapshots are Maven repos and cannot host OCI artifacts. Helm 3.8+ has OCI support on by default.

Scope

• New workflow (or a release job) triggered on a version tag — the repo currently has no tag trigger, so the trigger itself is new. Decide the tag convention (e.g. federation-v0.3.2, since a future second chart in this repo would collide with a bare v*).
• Re-add JFROG_USER / JFROG_PASSWORD repo secrets (same pair the arrow and jdbc release workflows already use).
• Guard against re-publishing an existing version — Artifactory should reject an overwrite, and CI should fail loudly rather than silently succeed.
• Verify the published artifact after push (helm pull oci://… --version <v> then helm template it), mirroring the "don't trust a green publish" lesson from the es7-bridge empty-jar incident.
• Docs: update softclient4es-federation/README.md (Install/Upgrade) and docs/operator-guide.md to lead with the OCI install and keep the local-checkout form as the dev/contributor path.
• Keep the existing static gates unchanged; publishing must not weaken lint / kubeconform / golden-diff.

Acceptance criteria

1. Pushing the agreed tag publishes softclient4es-federation-<Chart.yaml version>.tgz to the JFrog OCI repo, and the workflow fails if the version already exists.
2. helm install fed oci://softnetwork.jfrog.io/<helm-repo>/softclient4es-federation --version <v> works from a clean machine with no clone of this repo.
3. helm pull + helm template of the published chart renders identically to the committed goldens for the same version.
4. README + operator guide document the OCI install as the primary path.
5. Chart version and appVersion semantics stay as they are: version = chart SemVer (the artifact version), appVersion = the arrow image tag.

Open questions

1. Repository name and anonymous read. What should the OCI repo be called (e.g. helm, charts, helm-releases), and does it allow anonymous pulls? The chart is customer-facing, so operators must be able to helm install without SOFTNETWORK credentials — otherwise this is strictly worse than the current git-clone flow. This is the blocking decision.
2. Snapshots. Publish pre-release chart versions (e.g. 0.3.3-SNAPSHOT) from main, or releases only?
3. Provenance. Sign charts with helm package --sign / publish a .prov? Optional, but easier to adopt now than retrofit.
4. DockerHub alternative. OCI charts can also live next to the images on DockerHub. JFrog keeps the artifact story consistent with the jars; worth an explicit decision rather than defaulting.

Context

• Current chart: version: 0.3.2, appVersion: "0.2.2" (arrow 0.2.2 / elasticsql core 0.20.1).
• JFrog base softnetwork.jfrog.io/artifactory, existing Maven repos releases and snapshots.
• Images stay on public DockerHub (softnetwork/softclient4es-federation, softnetwork/softclient4es{6,7,8,9}-arrow-flight-sql) — unchanged by this issue.