fix(release): reconnect GitHub Releases, enforce tag-parity, fix install docs

[lucasmundim]

Problem

The chart-publishing migration (Pages → Docker Hub → GHCR, #53 / #71 / #75) moved the artifact but left the release surface disconnected:

1. Nothing shows on GitHub Releases. Releases were a side-effect of chart-releaser (helm-release.yml), removed in feat(deploy): implement auto-bump flow and move chart to deployment/ #53. The replacement docker-publish.yml only does helm push → GHCR + image push → Docker Hub; it never creates a Release. So v0.6.0 / v0.6.1 are bare tags and the Releases page is frozen at the May 5 chart-releaser fossil openfilter-pipelines-controller-0.5.1.
2. The parity lint was vacuous. It only checked version == appVersion (both 0.5.1 → green) and its error message pointed at .github/workflows/update-helm-version.yml, a workflow feat(deploy): implement auto-bump flow and move chart to deployment/ #53 deleted.

The published artifact itself is fine: chart 0.6.1 is publicly pullable from oci://ghcr.io/plainsightai/charts/openfilter-pipelines-controller, and external installs are already deterministic (the publish job bakes --app-version from the tag, and values.yaml image.tag is "" → defaults to appVersion).

Changes (zero rendered-manifest impact — lab/staging/prod untouched)

1. docker-publish.yml — recreate a GitHub Release per tag with the packaged chart .tgz attached and auto-generated notes (job permission → contents: write).
2. lint.yml — the parity check now also asserts Chart.yaml matches the release tag on a vX.Y.Z push; removed the dead update-helm-version.yml reference; Go lint skipped on tags.
3. Docs — README.md and the chart README.md lead with the GHCR install at the correct version, plus a Releasing section documenting the tag-driven flow the parity gate enforces.

Deliberately NOT bumping Chart.yaml here

version/appVersion feed the app.kubernetes.io/version pod-template label, so an out-of-band bump would roll the controller in every env on the next ArgoCD sync (image is SHA-pinned, so it'd be a no-op restart — but still out-of-band). External GHCR installs don't need it (publish bakes --app-version from the tag). The parity gate now forces the in-repo bump at release time, coupled to a real release where a rollout is expected.

New release process (enforced by CI)

1. Bump version and appVersion in Chart.yaml to X.Y.Z via PR.
2. Tag the merged commit vX.Y.Z and push — CI publishes images + chart to GHCR and creates the GitHub Release. Tagging a commit whose Chart.yaml doesn't match now fails the parity gate.

Compatibility with the in-flight deploy refactor (@stwilt, DT-164/166)

This PR only touches lint.yml, docker-publish.yml, and READMEs — no overrides/*, no image key paths, no deploy/deploy-lab jobs. It does not depend on gitops#130/#62 landing and does not conflict with them (ArgoCD renders the in-repo chart; this changes none of it).

Validation

• helm lint clean (pre-existing icon INFO only); both workflows parse as valid YAML.
• Parity simulated: v0.6.1 → PASS, v0.6.2 → FAIL (requires a bump first).

Follow-ups

• Companion PR on plainsight-deployment-agent for the same release surface plus an image-tag determinism fix (its chart defaults image.tag to latest, which is the root cause of the customer missing required media_id incident).
• Per fix(ci): publish Helm chart to GHCR to stop clobbering the image tag #75: confirm the GHCR chart package visibility is public.

[shingonoide]

Thanks for reconnecting the Releases pipeline. The core fix is sound: v0.6.0 and v0.6.1 exist while the Releases page is still frozen at openfilter-pipelines-controller-0.5.1, so re-adding gh release create/upload on tag push is the right call, the view-then-clobber pattern is safe to re-run, and the documented OCI install path resolves to what helm push actually produces. CI is green.

Two points before this counts as a hard guarantee:

1. The parity gate does not actually block a bad publish. chart-version-parity runs in lint.yml, while the chart publish and Release creation run in docker-publish.yml. The two workflows trigger independently on the same tag push with no cross-workflow dependency (no needs, no workflow_run), and there is no required-status-check ruleset on tag pushes. A tag whose Chart.yaml does not match will fail the parity job in lint.yml while docker-publish.yml still publishes the mismatched chart and creates the Release. The deployment README wording ("a stale Chart.yaml fails CI before anything is published") overstates this: the gate detects drift but does not prevent the publish. Please move the parity assertion into docker-publish.yml's publish-chart job (or make publish-chart depend on it) so the guarantee actually holds, or soften the README wording to match.

2. The Go-lint skip guard is broader than the trigger. lint.yml uses if: !startsWith(github.ref, 'refs/tags/'), which skips Go lint on any tag ref, while the trigger only admits v*... Harmless today, but if the tag trigger is ever widened, Go lint would silently skip. Tightening the guard to match avoids that latent footgun.

Nits (non-blocking): the Release naming moves to git-tag style (v0.6.1) versus the historical chart-releaser style (openfilter-pipelines-controller-0.5.1), a small discontinuity on the Releases page; and the 0.6.1 pins in the install examples will go stale on the next release, though the added "track the git tags" prose mitigates that.

[leandrobmarinho]

The release-process reconnect itself is correct and well-verified: the in-job 'Assert Chart.yaml matches the release tag' step now genuinely gates the publish from inside publish-chart (set -eu/exit 1 before package/push), the Create-Release step is idempotent (view -> upload --clobber, else create), the tgz name matches helm package output, and contents:write is the right minimum permission. One doc-accuracy issue inline.

[lucasmundim]

Thanks for the careful review — both points are addressed in 19491d6 (pushed after this review):

1. Parity gate now blocks the publish. I moved the Chart.yaml == tag assertion out of lint.yml into docker-publish.yml's publish-chart job as the Assert Chart.yaml matches the release tag step (set -eu / exit 1 before package/push), so a mismatched tag fails the publish itself rather than just an advisory lint check. The README wording was re-pointed to this gate in 8668ee4.
2. Go-lint skip guard removed. I dropped both the tags: trigger and the if: !startsWith(github.ref, 'refs/tags/') guard from lint.yml, so there's no tag-ref skip left to widen.

On the nits: the vX.Y.Z Release naming is intentional (the new flow tags git tags rather than chart-releaser names), and the 0.6.1 doc pins are knowingly version-pinned, mitigated by the "track the git tags" prose.

[leandrobmarinho]

Re-reviewed at the current head (8668ee4). My README finding is fixed: the Releasing section now correctly states that lint.yml's chart-version-parity is a PR-only version==appVersion check that never sees the tag, and credits the actual tag-parity gate to the 'Assert Chart.yaml matches the release tag' step in docker-publish.yml's publish-chart job (with a matching clarifying comment added in lint.yml itself) - so the docs no longer risk a maintainer removing the real gate. The release-process reconnect mechanics were already verified: the in-job assert gates the publish from inside publish-chart (set -eu/exit 1 before package/push), the Create-Release step is idempotent (view -> upload --clobber, else create), the tgz name matches helm package output, and contents:write is the right minimum permission. Looks good.