search

opensearch-project / helm-charts

:wheel_of_dharma: A community repository for Helm Charts of OpenSearch Project.
https://opensearch.org/docs/latest/opensearch/install/helm/
Apache License 2.0
173 stars 235 forks source link

[Enhancement] Update chart versions in CI #609

Open cyanidium opened 1 month ago

cyanidium commented 1 month ago

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.

prudhvigodithi commented 1 month ago

[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

cyanidium commented 1 month ago

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.