feat(deploy): unify image + chart publishing under Docker Hub OCI

[lucasmundim]

Opening as draft for coordination — see the note about @stwilt's in-flight PRs at the bottom. Happy to rebase / merge / wait based on what makes the most sense for the deploy-flow direction.

Summary

Replaces the GAR-coupled deployments.yml workflow with a single docker-publish.yml modeled on the plainsight-deployment-agent workflow but extended to cover this repo's two-image build (controller + claimer) and to publish the Helm chart as an OCI artifact alongside the images.

End state, per release:

• plainsightai/openfilter-pipelines-controller:<sha> + :vX.Y.Z + :latest (multi-arch)
• plainsightai/openfilter-pipelines-claimer:<sha> + :vX.Y.Z + :latest (multi-arch)
• oci://registry-1.docker.io/plainsightai/openfilter-pipelines-controller:X.Y.Z (Helm chart, version-pinned to the git tag)

Changes

.github/workflows/

• deployments.yml removed, docker-publish.yml added. The new workflow:
  • Builds both images (controller, claimer) across amd64 + arm64, pushes-by-digest to the two Docker Hub repos. PR triggers build-but-no-push so reviewers get the same compile signal as main without leaking PR digests to a public registry.
  • Merges per-arch digests into a multi-arch manifest tagged with the commit SHA, the semver tag (on tag pushes), and latest (on tag pushes only — main never bumps latest, matching the deployment-agent contract so prod doesn't accidentally pull a dev SHA).
  • On refs/tags/v*.*.*, packages the Helm chart under deployment/openfilter-pipelines-controller and pushes it to oci://registry-1.docker.io/plainsightai/openfilter-pipelines-controller. The chart's --version and --app-version both track the git tag (vX.Y.Z → X.Y.Z), keeping image + chart releases in lock-step so a single git tag produces a self-consistent install.
  • Preserves the existing deploy + deploy-lab jobs on main pushes — same reusable PlainsightAI/gh-actions-public workflows, same service-name: openfilter-pipelines-controller + manifests-path: deployment contract. The override-bump automation downstream is unchanged.

Makefile

• Default IMG / CLAIMER_IMG flipped from a GAR-prefixed pattern (gated on an env var) to plain plainsightai/openfilter-pipelines-controller / plainsightai/openfilter-pipelines-claimer. A local make docker-build now produces the same image name a release would, so OSS contributors don't need any env variable to reproduce the published shape.

deployment/openfilter-pipelines-controller/overrides/{development,lab,staging,production}.yaml

• image.repository and claimerImage.repository switched from us-west1-docker.pkg.dev/plainsightai-prod/oci/openfilter-pipelines-* to plainsightai/openfilter-pipelines-*. The tag pins (with the $imagepolicy Flux annotation) are unchanged — the image-policy automation only rewrites the tag field, not the repository, so this commit doesn't perturb the bump-PR cadence.

deployment/openfilter-pipelines-controller/README.md

• New top-level "Install from Docker Hub (recommended)" section documenting:

  helm install openfilter-pipelines-controller \
    oci://registry-1.docker.io/plainsightai/openfilter-pipelines-controller \
    --version 0.5.1

  with links to the two Docker Hub image repos. The local-chart install instructions are kept as the fallback for contributors hacking on the chart.

Validation

• helm dependency update + helm lint clean against the chart (only the pre-existing icon-recommended INFO).
• helm template against overrides/development.yaml renders image: plainsightai/openfilter-pipelines-controller:<sha> as expected; no remaining us-west1-docker.pkg.dev strings in the rendered manifests.

Migration / wire compatibility

• Image registry switch is one-way for new pushes. After this PR lands, GAR stops receiving new tags from CI. Existing GAR tags stay readable (cluster nodes already cached the layers), but anything that pulls a new SHA needs the Docker Hub credentials wired into the node pool image-pull secret. Worth confirming the prod cluster has access to plainsightai/* on Docker Hub before merging.
• No Helm chart consumers exist yet at the OCI endpoint — this PR is what bootstraps the registry. The first published chart will be whatever v*.*.* tag we cut next.
• The deploy + deploy-lab jobs use the same PlainsightAI/gh-actions-public reusable workflows, so the override-bump automation in the deployment repos is untouched.

Coordination

Two of @stwilt's PRs are in flight and overlap with the deploy surface:

• openfilter-pipelines-controller#62 (DT-164) — refactor deployments workflow to remove direct gitops pushing
• gitops#130 (DT-166) — configure ArgoCD Image Updater annotations

This PR intentionally does not touch the gitops side and keeps the deploy jobs as-is. Once @stwilt's PRs settle, we should align on (a) whether this docker-publish.yml keeps deploy / deploy-lab or hands them off to the new flow, and (b) whether the ArgoCD Image Updater annotations in gitops want a different repository path now that we're on Docker Hub. Marking this draft to leave room for that conversation.

Test plan

• helm lint passes
• helm template renders Docker Hub paths
• (post-merge or via dry-run) Trigger a workflow_dispatch on main to confirm the build + push + merge + deploy chain end-to-end against Docker Hub credentials
• (post-first-tag) Verify the published chart installs cleanly via helm install oci://...

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[stwilt]

Clean migration — the GAR→Docker Hub swap is minimal and correct, the multi-arch digest-based build pattern carries over intact, and deploy/publish-chart gates are properly conditioned. Minor items below.