[ENHANCE] Find a different way to release helm charts, instead of commits to master branch
MuneebAijaz opened this issue · comments
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 #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.
We could have the chart here https://github.com/stakater/charts/ and let Renovate bump the version when needed
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.
@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.
@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?
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.
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
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.