Open jessebot opened 7 months ago
This action should also bump the version automatically when a conflict happens, right?
That's correct! It wouldn't be able to resolve anything but the Chart version
, but we can also make sure it keeps the appVersion
up to date, but that would also entail making sure that the PR isn't the user just bumping the appVersion anyway, which adds a tinsy bit of complexity here, but not much.
Description of the change
Create a GitHub Workflow to update the helm chart
version
in Chart.yaml on a feature/fix branch on pull requests based on a pull request Label.Labels to update on:
patch
,minor
,major
This action should bump by 1 in a single octet*, so here's an example scenario:
main
branch is4.5.6
.patch
The GitHub workflow should do the following:
patch
version
in Chart.yaml on themain
branchpatch
octet, making the suggested version4.5.7
4.5.7
on their feature/fix branch in their PRBenefits
This would be a huge benefit, because then the version would be auto-bumped and we don't have to poke users to do that, which sometimes extends the lifetime of a PR by months, depending on both maintainer and community member capacity. This can help us move a bit quicker to process PRs en-masse when one of us has a day or two to dedicate to this, while still allowing us to keep just one or two changes per release version, which makes troubleshooting and rolling back easier.
Possible drawbacks
A user HAS to check the "allow edits by maintainers" when opening their PR, or this will not work, but we encourage users to do that anyway, so that we can update small things like grammar, version numbers, and spacing without having to ping the user each time.
Additional information
I originally brought this up in https://github.com/nextcloud/helm/pull/356#discussion_r1390232626