-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support automatic semVer with conventionalCommits #19
Comments
FWIW it is possible to use semantic release with the CD process, there's an example here: But then that requires conventional commits which aren't really used in the Jenkins ecosystem |
From what I read, using https://github.com/jenkins-x-plugins/jx-release-version would conflict with what is documented in https://www.jenkins.io/doc/developer/publishing/releasing-cd/. The conventional-commits-plugin is omitting I think it would be good to document that approach as an option to CD. It would also require some settings on the repository, such as Squash & Merge option to be enforced, and a status checks to have https://github.com/zeke/semantic-pull-requests or something similar enabled and configured. @jglick |
Hi @agaudreault-jive, the reason we went with |
I could not recommend the approach taken in mvn -Dset.changelist install would produce the desired versioned artifact. In that case |
Tried to transfer this to https://github.com/jenkinsci/incrementals-tools/issues but that seems impossible as it is in a distinct GitHub organization? |
Yeah unfortunately you can't transfer across organisations. multi-organisation places normally work around it with a bot which re-reports it with a backlink and a comment on the side it was 'transferred' from. |
Allow the developers to use the SemVer scheme with the CD workflow. It is possible to fully generate a semantic version based on the commit message and history.
For instance, if the last semantic Tag in the current branch is
1.0.0
and a commit is made starting withfeat:
, the next release will be1.1.0
. The current JEP-229 generate version numbers such as{digit}.v{hash}
that lose all meaning of changes. When a Jenkins maintainers needs to bump a plugin, it is impossible to know at a glance if it contains breaking change or not. The developers will have to do a comparison of the git history and try to find any breaking change. The proposed way to do that is to keep themajor.minor
part of the version manual, which defeat the purpose of automating the version and release process.Generating a semantic version number based on commit history has many advantages:
Tools such as Semantic Release offers many libraries to perform the automation based on existing and widely adopted conventions. The library also allows maintainers to customize release rules of their projects for their needs instead of forcing them in a box. The CI can still enforce some configuration by merging the 2 with a precedence order.
Suggested version scheme would be
{history_depth}.v{commit_hash}
(0.vabcd1234
) semver: 🚫{semver}+{commit_hash}
(0.0.0+abcd1234
) semver: ✅{prefix}.{history_depth}.v{commit_hash}
(0.0.0.vabcd1234
) semver: 🚫0.0.0+abcd1234
) semver: ✅{wrapped_semver}-{history_depth}.v{commit_hash}
(1.0.0-0.vabcd1234
) semver: ✅{wrapped_semver}-{semver}+{commit_hash}
(1.0.0-0.0.0+abcd1234
) semver: ✅Related to jenkinsci/jep#383 (comment)
The text was updated successfully, but these errors were encountered: