stakater
[ENHANCE] Find a different way to release helm charts, instead of commits to master branch
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 https://github.com/stakater/Reloader/issues/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: https://github.com/stakater/Reloader/commit/8595b4ac43b1882f069feeb40f7038cec6fb5e4c
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.
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.