Release jobs are triggered for renovate bot PRs

[kravciak]

Example PR: chore(deps): update actions/checkout action to v4.2.2

Release job: https://github.com/kubewarden/helm-charts/actions/runs/11551186609
E2E tests: https://github.com/kubewarden/helm-charts/actions/runs/11551207278

[viccuad]

There's 2 issues in play:

A. chart releaser incorrecly re-releases things with suffic -foo, like RCs, alphas and betas.

1. chart-releaser is configured with env var CR_SKIP_EXISTING to true, which is the best we can do. This means chart-releaser doesn't publish the built releases, but still creates them under .cr-release-packages.
2. chart-releaser seems to incorrectly update chart metadata that sits on index.yaml. But weirdly, this only happens for RCs or alphas and betas.
   • See: https://github.com/kubewarden/helm-charts/blob/gh-pages/index.yaml#L51-L330
   • See: https://github.com/kubewarden/helm-charts/blob/gh-pages/index.yaml#L615-L802

B. We look if there's new charts under .cr-release-packages/ and if there are, we create provenance and push the provenance. This file creation happens regardless of chart-releaser configuration on pushing the releases, so it's a wrong assumption.

Examples

For example, the following PR: #542

1. Was merged after having released kubewarden-defaults-2.4.0-rc3.
2. The release job from main says that it updated the index.yaml on the gh-pages branch, https://github.com/kubewarden/helm-charts/actions/runs/10989803081/job/30508724279#step:11:97, overwriting the kubewarden-defaults-2.4.0-rc3 GH release with a new chart that would have contained the PR fix. But actually it didn't.
3. the fix is correctly shipped in the next release kubewarden-defaults-2.4.0-rc4.

Same for the following PR: #567

1. Was merged after having released [kubewarden-controller-3.1.0-beta1](https://github.com/kubewarden/helm-charts/releases/tag/kubewarden-controller-3.1.0-beta1).
2. The release job from main says that it updated the index.yaml on the gh-pages branch,
   https://github.com/kubewarden/helm-charts/actions/runs/11514993120/job/32054746937#step:10:98
   , overwriting the kubewarden-controller-3.1.0-beta1 GH release with a new chart that would have contained the PR fix. But actually it didn't.
3. On the workflow run, we see the new bogus .cr-release-packages/kubewarden-controller-3.1.0-beta1.tgz file, and incorrectly sign it, push to the OCI registry, create provenance, and push that too.

Merged: #575
https://github.com/kubewarden/helm-charts/actions/runs/11596378269
this resulted in a new kubewarden-controller-3.1.0-rc1 release: 933f1be

Result

A seems incorrect for rcs,alphas,betas. We can open an issue in chart-releaser. This will stop the re-release of those, but doesn't solve our problem with B.

For B, we need to be aware on when do we have a real release at hand, to push to OCI registry on our own. This could be achieved by dropping the usage of the helm/chart-releaser-action GHA, and doing on our own:

for each chart:
  cr package <chart> # create .cr-release-packages/chart.tgz file that we use to know if we need to push, sign, etc
  <check if GH Release or tag exists matching the version of the chart.tgz with helm show, stop here if it does>
  cr upload <chart> # upload chart.tgz to GHA, skipped if CR_SKIP_EXISTING
  cr index # update index.yaml in branch gh-pages. If no cr upload, this means bogus entries

  helm push chart.tgz oci://repo
  cosign sign oci://repo@digest
  <create attestations and push>
end for