Open lemeurherve opened 3 years ago
@lemeurherve any idea on how this would work in practice? How do you automatically decide if it's a breakting change or not?
From the commit message? Not sure if easily feasable here, but when using jenkins-x for example, if a commit contains "feat:" (for example), it would generate a minor version, and if it contains "breaking:" it would generate a major version.
It could also be a label added to the breaking PR by a maintainer to force a major version (maybe? I'm not yet familiar with the possibilities for these automations with the current infra)
EDIT: also saw https://www.jenkins.io/blog/2021/07/30/introducing-conventional-commits-plugin-for-jenkins/
EDIT: ftr, here how it's done with jx, note for self in order to reimplement it with Jenkins: https://github.com/jenkins-x/jx3-pipeline-catalog/blob/master/tasks/typescript/release.yaml#L48-L98
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
Is your feature request related to a problem? Please describe. When updating the chart, we have to manually bump the chart version (and update the changelog). It should (IMHO) be automatic, and would avoid the need to update a PR if another has been merged meanwhile.
There is also the fact that some checksums have to be updated, I didn't completly understood how, I've used
ct lint
to get the correct one hereDescribe the solution you'd like Update automatically the chart version and checksums (and the changelog?) when the PR is merged on the main branch.
Additional context Made these observations while preparing this PR: https://github.com/jenkinsci/helm-charts/pull/478