[Enhancement][GitHub Actions] Add GitHub Action to auto bump chart version

[peterzhuamazon]

Is your feature request related to a problem? Please describe.
[Enhancement][GitHub Actions] Add GitHub Action to auto bump chart version

Right now we require PR creator to bump the chart version when they raise the PR,
so that the chart releaser can release a new version after merge.

It will be much easier to have a version autobumper, take action after a PR is merged,
and will resolve edge cases where multiple PRs change to the same 1.x.x version and conflict against each other if any of them merge 1st.

Describe the solution you'd like
See above.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[smlx]

One way this could work is to start enforcing a standard like https://www.conventionalcommits.org/en/v1.0.0/

[mprimeaux]

One way this could work is to start enforcing a standard like https://www.conventionalcommits.org/en/v1.0.0/

This is certainly an option.

I've been reasoning about this a bit and believe the options partially depend on how the maintainers prefer this repository to operate.

For example, do you prefer to (1) use feature, defect, technical debt, and technical risk branches only or (2) also prefer to represent release branches? Other?

Kubernetes employs long-lived release branches so fixes can easily be made to those versions in support of their deprecation policy. It appears OpenSearch is also going this route.

Is the desire to remain with Github flow or be somewhere between Github flow and Git flow?

On a related note, I've implemented the GitVersion GitHub action in workflows for our platforms. Though originally more .NET focused, it works for our non-Microsoft stack.

I am still researching options.

[DandyDeveloper]

@mprimeaux The only thing to remember is you'll have people all over contributing here.

Definitely defining something already familiar to the OSS (particularly Kubernetes/CNCF) communities would hopefully be easier to take onboard for most.

I'm not going to weigh in with any additional options as all the above are good. I think owners need to make the call on what gets done.

+1 in favour of long lived feature branches (Less for the hot fixing, and more for the coherent releases).

[TheAlgo]

@mprimeaux @DandyDeveloper
I am totally with you guys on long-lived branches. Initially we started off with 1.0.0 but never followed it after that. In my opinion this will help us draw a line on the number of releases we make as well.

Thinking loud, we can release charts weekly or biweekly and have special slots for any serious bugs or issues. This can streamline the releases and reduce the pain of the contributors as well.

[smlx]

Thinking loud, we can release charts weekly or biweekly and have special slots for any serious bugs or issues. This can streamline the releases and reduce the pain of the contributors as well.

The helm CI tooling is geared for fully automated continuous releases on every MR instead of a manual release process. Is there a problem with automating releases that way?

[TheAlgo]

Thinking loud, we can release charts weekly or biweekly and have special slots for any serious bugs or issues. This can streamline the releases and reduce the pain of the contributors as well.

The helm CI tooling is geared for fully automated continuous releases on every MR instead of a manual release process. Is there a problem with automating releases that way?

There is no problem if we can reach on a consensus on how version bump can be automated. I don't mind agile way of releases any day

[peterzhuamazon]

As of now there are multiple 1.0.5 version bump PRs in this repo, and we need to constantly ask people to bump their version because another PR has taken over his bumped version number already.

This is a bit worrying to me.
We either disable the version bump requirement or we have an automated way to do this.

Any thoughts?

Thanks.

[smlx]

We either disable the version bump requirement or we have an automated way to do this.

Another option is to focus on getting PRs reviewed and merged much more rapidly. I'm thinking in the order of days rather than weeks,.

[DandyDeveloper]

@smlx I do agree the speed could be significantly improved in getting things in.

But I really think having an automated rollout from a feature branch, even daily, can work.

[peterzhuamazon]

Hi @DandyDeveloper @TheAlgo @mprimeaux @smlx we need to find a solution for this quick.
As the number of PRs coming in we cannot just keep pinging authors to bump versions.

What about a auto bumper which will check the version:

• If author bumped the version and it is correct version, leave it.
• If author bumped the version but wrong version, auto bump patch.
• If author did not bump anything just bump patch version and auto commit changelog with PR title as content.

What do you think about this?

Thanks.

[TheAlgo]

I am fine with this auto bumper but I have some concerns around this which pushes me in favour with feature branches rollouts.

If author bumped the version and it is correct version, leave it.
If author bumped the version but wrong version, auto bump patch.
If author did not bump anything just bump patch version and auto commit changelog with PR title as content.

How will the auto bumper determine the Semantic versioning from the PR? Is there something , I am not aware of anything , there might be something in place though.
Committing just the PR title should not be a good practice. Going forward we should have some guidelines for it. There might be many organisations who will see the CHANGELOG and install the charts

[mprimeaux]

@peterzhuamazon If we (1) move to long-lived release branches, (2) embrace GitHub flow with main being the trunk, and (3) relax the linting to main, we could then relax the --check-version-increment check for all PRs to main and ensure it is enabled for PRs to the release branches thus not needing to deal with an auto-bumper.

[mprimeaux]

@peterzhuamazon Would you and the maintainers like me to start on a PR and related steps to move in this direction?

[TheAlgo]

@mprimeaux @peterzhuamazon For now it looks to me that long lived release branches is the way forward. This will get frustrating for contributors in the long run.

[peterzhuamazon]

What would be the actions if we plan to go either way?

[TheAlgo]

Seeing the current scenario I feel we can start off with long lived release branches. If everyone is okay with it I can create one. We can have those branches merged to main after the patch is ready so one and so forth.

[peterzhuamazon]

Seeing the current scenario I feel we can start off with long lived release branches. If everyone is okay with it I can create one. We can have those branches merged to main after the patch is ready so one and so forth.

Do you have a flow in mind of how long lived branches would work?
For example, a simple few lines on how do we backport changes to these long-lived branch and maintain them alongside the main branch.

Thanks.

[peterzhuamazon]

We have resolved this by adding community guidelines.
#169