Fix Helm chart version synchronization

[Emre Şafak (esafak)]

Why?

The Helm chart and Garnet application have independent release lifecycles, but the chart metadata was coupled to the application version. Upstream releases also left the published chart and checked-in README metadata stale because chart version changes were not part of the application release process.

This PR will...

• Keep Helm chart version independent from Garnet appVersion (0.2.3 and 2.1.5 respectively).
• Keep the standard Helm-generated chart Version and AppVersion badges in charts/garnet/README.md.
• Require chart source changes to increase the chart version and keep appVersion synchronized with Version.props.
• Reject stale generated README content in pull requests.
• Publish only after chart source changes, with least-privilege workflow permissions and no force-pushed helm-docs-gen branch.
• Create or update a bot PR when Version.props changes; the bot increments the chart patch version, updates appVersion, and regenerates the README before publication.

The release bot performs patch bumps only. Maintainers can choose chart minor or major versions manually when chart compatibility changes require it.

Testing

• actionlint .github/workflows/helm-chart.yml .github/workflows/helm-chart-check.yml .github/workflows/helm-chart-release-sync.yml
• git diff --check
• helm lint charts/garnet
• helm template garnet charts/garnet
• helm template garnet charts/garnet --set image.tag=1.0.65
• helm package charts/garnet
• Pinned helm-docs 1.14.2 regeneration and README consistency check

[Emre Şafak (esafak)]

@microsoft-github-policy-service agree company="Archipelago AI"

[Emre Şafak (esafak)]

@microsoft-github-policy-service agree company="Archipelago AI"

[Copilot]

Pull request overview

Synchronizes Helm chart metadata with Garnet’s canonical release version and broadens OCI publishing triggers.

Changes:

• Aligns chart version and appVersion with Version.props.
• Validates version consistency before packaging.
• Triggers publishing for all chart and version changes.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
charts/garnet/Chart.yaml	Updates chart metadata to version 2.1.5.
.github/workflows/helm-chart.yml	Expands triggers and adds version validation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Badrish Chandramouli (badrishc)]

babykart (@babykart) - could you review this PR? Thank you.

[babykart (babykart)]

I see at least one major issue with this MR:
It aligns version and appVersion, thereby equating the evolution of the Helm chart with that of the application itself.
This approach is problematic for several reasons:

• Loss of Differentiation: By forcing version (chart) and appVersion (application) to be identical, it becomes impossible to distinguish between changes made to the chart (e.g., fixes to templates, new configuration options) and changes made to the application (e.g., new features, bug fixes). Users cannot tell if a chart update contains application changes or just chart improvements.
• Inflexible Release Cycle: A minor update to the chart (e.g., fixing a typo in a template or adding a new values.yaml option) currently requires bumping the application version in Version.props. This is semantically incorrect and creates confusion:
  Example: If the chart is updated to support a new Kubernetes feature, but the application remains unchanged, the chart version should be incremented independently (e.g., from 0.2.2 to 0.2.3). However, the current process forces the application version to also be bumped, even though no application code changed.

Ideally—and I was the first to overlook this—whenever the Helm chart is modified, the version key should be incremented; this would trigger the generation of the README.md (...) and publication to the registry.
However, the release process for the Garnet application does not currently modify this version key, which would otherwise ensure the chart gets published.
In short, to quickly fix the issue where the Helm chart lacks the correct appVersion, we simply need to create an MR that increments the version key.

If we want to automate the Helm chart publishing process, we need to consider two scenarios:

• There are only modifications to the Helm chart, in which case the version key must be incremented accordingly (fix, feature, etc.).
• There is a new Garnet release: the version key must be updated—whether manually or automatically...

[Emre Şafak (esafak)]

Very well, I decoupled them again. Chart/app changes will trigger patch updates. If you want major/minor changes you can do it manually.

You can see the results of merging https://github.com/esafak/garnet/pkgs/container/helm-charts%2Fgarnet and https://github.com/esafak/garnet