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

[Enhancement] Update chart versions in CI #609

Open
cyanidium opened this issue Oct 20, 2024 · 2 comments
Open

[Enhancement] Update chart versions in CI #609

cyanidium opened this issue Oct 20, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@cyanidium
Copy link
Contributor

Is your feature request related to a problem? Please describe.
I just created two pull requests to remove a total of 4 characters from main and 1.x, which required a few dozen line changes to bump the version which are not well documented (i.e. I didn't even realise there was a compare link to update until the third go). If anyone merges a PR before mine, I'll have to go back and rebase those dozens of lines. This is quite inconvenient for someone wanting to contribute a small fix.

Describe the solution you'd like
Is there a CI process in a GitHub Action or something that could automatically update the version and the changelog? That could run when the PRs are merged to update this information and prevent PRs getting stuck while waiting for someone to rebase them.

@cyanidium cyanidium added enhancement New feature or request untriaged Issues that have not yet been triaged labels Oct 20, 2024
@prudhvigodithi
Copy link
Collaborator

[Triage]
Thanks for bringing this @cyanidium,

I agree that we need a better process for incrementing chart versions and updating the changelog. Instead of updating the version and changelog for every PR, we could do this for a batch of PRs. For example, we could define a target release version, merge the PRs, and upon tag creation, release the Helm chart. This is similar to what we do today for the OpenSearch operator Helm chart (see: OpenSearch Operator Release Workflow). The main advantage is that we don't have to update the version and changelog for every PR, which can delay merging, but instead handle it during the tag creation process. The downside is that merged features will have to wait for the release, so it's not an instant process.

Another approach is have an automation built that can update the changelog for every PR, I'm open for thoughts and @cyanidium if you have any process in your mind please share and we can move forward with the implementation.

Thank you
@getsaurabh02 @gaiksaya @TheAlgo @smlx

@prudhvigodithi prudhvigodithi removed the untriaged Issues that have not yet been triaged label Oct 24, 2024
@cyanidium
Copy link
Contributor Author

If you're willing to change the workflow, I would encourage the first option of using a tagging workflow rather than trying to automate. All of the automatic tools I've seen (including external services and GitHub Actions) seem a bit "fragile", in particular when there are minor and bugfix version increment options. If there is an important change, there's no reason you couldn't start a tagged release immediately to get the change out just as fast as it releases now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🆕 New
Development

No branches or pull requests

2 participants