[ENHANCE] Find a different way to release helm charts, instead of commits to master branch

[MuneebAijaz]

Is your feature request related to a problem? Please describe.

Push workflow commits back to master branch which creates multiple issues:

• Back to back PRs can not be merged till one has completed its whole flow and committed back to master
• Permission issues for writing back to master branch Pipeline sometimes fails at the "Commit Files" step which prevents Release from being created unless manual intervention is done #636

Current need to write back to master branch:

• this branch hosts latest helm charts, which gets updates on labels, image number and chart versions on every PR merged. Example commit: 8595b4a

Describe the solution you'd like
Find a different strategy to release helm charts and plain manifests instead of committing back to master branch.

Describe alternatives you've considered

• Create versioned branches to host helm charts
• Push to different repo to host helm charts for opensource repos, instead of code repos.

Additional context
Add any other context or screenshots about the feature request here.

[karl-johan-grahn]

We could have the chart here https://github.com/stakater/charts/ and let Renovate bump the version when needed

[onedr0p]

Team, I love using reloader but since I am using renovate to update it in my clusters the churn of releases are getting overwhelming. Any chance this can be addressed to not release on every merged PR to the main branch? Does every merged PR warrant a new release? Thanks.

[MuneebAijaz]

@onedr0p can you pls open a separate issue so we can track it properly? since your request is regarding how releases are made in general; this issue doesn't cover that.

[MuneebAijaz]

@karl-johan-grahn i guess that works for charts. what do u suggest for plain manifests? for example https://github.com/stakater/Reloader/tree/master/deployments/kubernetes/manifests

separate folder in the charts repo under Reloader directory for plain manifests?

[karl-johan-grahn]

I'm not sure about the plain manifests, but overall I strongly agree that the logic of having push workflow committing back to master branch is unintuitive and unnecessarily complex.

[MuneebAijaz]

One other way is to let renovate run here for charts etc as well, then it wont be a direct commit to main, instead it will be via a PR.
but the entire flow will change.

• Releaser will have to run after push workflow, instead of running on push commit to master event.
• After new git release has been created, then renovate will pick the tag, create the PR and apply it.

But yeah i'd prefer charts to be moved to stakater/charts repo

[MuneebAijaz]

If we conclude on moving charts, let's put a notice/note on repo about moving charts, and plan it in our backlog.

It will still be open for contributors to implement it if they want.

[karl-johan-grahn]

Ideally the Reloader chart would just use the Stakater application chart. For now, I think the best option is to move the current chart to the Stakater charts repo.