Simplify chart change detection

[florisvdg]

In the README it says:

It does this – during every push to main – by checking each chart in your project, and whenever there's a new chart version, creates a corresponding GitHub release named for the chart version,

When reading this, I expected this action to do an actual chart version check (using the standard version field in the respective Chart.yaml). But when looking at the code, it surprised me that this action decides for itself when a new version should be released, by doing a git diff.

So when you merge to the configured branch, without necessarily expecting a release to be done, the action may still try to create a new release, which then results in:

Error: error creating GitHub release: POST https://api.github.com/repos/<repo>/releases: 422 Validation Failed [{Resource:Release Field:tag_name Code:already_exists Message:}]

Wouldn't it be simpler to just use the actual chart version for the chart-version check to determine whether to release?

I prototyped it in this PR and it works well (at least for my case).

Some caveats/things to note about the implementation:

• it does now enforce the default release-name-template of {{ .Name }}-{{ .Version }}
• there are dependencies on the yq and helm CLI

[ruckc]

I would prefer a chart diff for change detection, while also ensuring the chart version is different. I personally would like the diff appended to the release somehow as currently the details on what changed for a single chart between releases isn't easy to find when multiple charts exist in the same repository.

[codeclown]

👍 would prefer triggering new release only when the version number has changed. I keep getting myself into trouble by updating random files (e.g. making formatting adjustments to all READMEs in a repo), which then causes chart-releaser-action to try to release those charts and failing with the error creating GitHub release error, which blocks the release of charts I intended.

[BojanZelic]

👍 I find the default approach to not work for me because I use a symlink and a submodule to the charts directory. So it doesn't correctly pick it up. This PR would fix that however;

[Kerwood]

+1 I find the default approach to not work for me because I use a symlink and a submodule to the charts directory. So it doesn't correctly pick it up. This PR would fix that however;

Me too. Did you find a solution for it ?

[BojanZelic]

+1 I find the default approach to not work for me because I use a symlink and a submodule to the charts directory. So it doesn't correctly pick it up. This PR would fix that however;

Me too. Did you find a solution for it ?

I use a forked version of this repo https://github.com/zelic-io/charts/blob/main/.github/workflows/release.yml#L28

[Kerwood]

+1 I find the default approach to not work for me because I use a symlink and a submodule to the charts directory. So it doesn't correctly pick it up. This PR would fix that however;

Me too. Did you find a solution for it ?

I use a forked version of this repo https://github.com/zelic-io/charts/blob/main/.github/workflows/release.yml#L28

I ended up forking it and the make same changes as this PR.
Now I just add other repos as git submodules in a /charts dir.