feat: add new auto versionincrement field for helmchart resource
#1593
Conversation
|
This is a great idea which I like very very much and could be useful for any value updated within the chart so not only dependencies What would you think to rename "childdependent" to "auto" And add additional logic in if both source and new information are semver compliance, then we guess the new version This means that a container tag update could also trigger the correct version bump if the tag is semver compliant |
|
For information the failing check can be ignore by adding "childdependent" to |
|
Hey @olblak! I like your proposals a lot and will make the adjustments. I apologize for the delay in response as well; I was away on vacation and am just catching back up. Thanks for your suggestions! |
aroberts87
changed the title
child-dependent versionincrement field for helmchart resourceauto versionincrement field for helmchart resource
the intent of this change is to allow helm charts to have a version bump that corresponds with the highest level of bump done by a dependency rather than just a static major, minor, or patch increment. this will allow potential major or breaking changes in chart dependencies from being masked by a lesser increment done on the parent chart.
update the `child-dependent` name to something a bit more generic
Adapt the behavior of the `auto` version bump behavior to cause a minor version bump if either old or new target version is not a valid semver string. this will ensure that the legacy behavior of the default minor version bump will continue.
aroberts87
force-pushed
the
feat/dependency-consistent-version-bumps
branch
from
fc6745d
to
f6cba80
Compare
Thanks for the contribution and don't worry for the delay, I was a few day off as well. |
|
I like the idea behind the pullrequest very much, just a minor comment about downgrade scenarios |
in the `auto` version bump scenario we will now check if the new semver major, minor, and patch versions are not equal to the old ones rather than simply if the new version is greater than the old one. this will address the possibility of a downgrade scenario.
add a catch-all block for the `auto` version bump setting that will do a minor release bump if the old and new semver major, minor, and patch versions are identical which implies that the change must be in the metadata tags.
The intent of this change is to allow helm charts to have a version bump that is proportional to the version bump done by a dependency, rather than just a static major, minor, or patch increment. This will allow potential major or breaking changes in subchart dependencies from being masked by a lesser increment done on the parent chart, as well as larger version increments on the parent from looking more daunting than the changes they contain of the subchart bump is a lesser type.
As an example, with a simple one parent / one child chart relationship and the parent chart's starting version of
1.0.0, the new behavior yields the following behavior.Coupled with the functionality added in #1541, it will now be possible to have the following behavior when dealing with parent charts that have multiple subcharts with simultaneous version bumps during the same
updatecliinvocation.Test
To test this pull request, you can run the following commands:
Additional Information
Tradeoff
Potential improvement
Based on my testing running
applywith--push=falsebreaks the intended workflow as theoriginChartMetadatavalues do not appear to be updated with the cumulative updates betweenhelmcharttargets.I'm not married to the term
child-consistentfor describing the version bump type, but at the same time could not think of another concise way to describe the intent that I felt would be comfortable using as parameter.