Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
MuneebAijaz opened this issue Jun 11, 2024 · 8 comments
Labels
kind/enhancement New feature or request kind/help wanted Extra attention is needed

Comments

@MuneebAijaz
Copy link
Contributor

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

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

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.

@MuneebAijaz MuneebAijaz added kind/enhancement New feature or request kind/help wanted Extra attention is needed labels Jun 11, 2024
@karl-johan-grahn
Copy link
Contributor

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

@onedr0p
Copy link
Contributor

onedr0p commented Jun 11, 2024

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

MuneebAijaz commented Jun 11, 2024

@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
Copy link
Contributor

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
Copy link
Contributor Author

MuneebAijaz commented Jun 12, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request kind/help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants