Reputation: 9816
I am in the process of setting up a new hudson project and stumbled over the release plugin. You have basically two possibilities:
releaseVersion
and developmentVersion
- then the maven release plugin uses default values. (E.g 1.0.0-SNAPSHOT (svn) -> 1.0.0 version will be released (tag in svn) and 1.0.1-SNAPSHOT will be the next development version.) In most of the cases that is enough for us. However in certain cases (e.g. a major release should be build) it isn't enough.preRelease
and postRelease
actions like scripts etc. However if the plugin would be slightly more intelligent that wouldn't be necessary imho. So my question is: Is there a way without using before/after release build scripts to get the wanted behaviour?
The wanted behaviour is: The fields releaseVersion
and developmentVersion
should be prefilled with the actual version / version+1. If that is not possible then leaving those fields blank also suffice (if that triggers the default behaviour of the maven build plugin) If those fields are blank now, maven will be called with an empty parameter and thus fail.
(In different projects I have used jenkins in combination with the artifactory release plugin which is really easy - If a version should be released a page is show where all the versions are listed. If e.g. a major version should be build a user can easily change the numbers.)
Upvotes: 0
Views: 626
Reputation: 1549
I have had a similar problem, but the solution for me might have some significant overhead in your situation.
Jobs in my setup are not created manually but are instead generated using the Job DSL Plugin. This is the case because many similar jobs for different artifacts exist and generation tends to stop snowflake jobs from different users.
My solution looks something like this:
This was easily possible for me, as Job DSL was already in place and the name of each artifact is part of the jobname. It is far from perfect, as there can be points in time which do not show the correct version (right after a new release when the job creation hasn't been rerun).
Another option would be to create a custom Jenkins Plugin for this task, but it would likely carry even more overhead.
PS: I can try to include some more code samples if this solutions is a route you want to try.
Upvotes: 1