Lonzak
Lonzak

Reputation: 9816

Hudson / Jenkins release plugin: release version issues

I am in the process of setting up a new hudson project and stumbled over the release plugin. You have basically two possibilities:

  1. Don't define the String Parameters 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.
  2. Define those two values (cp. image, red markers) but then you always have to fill them and they are empty! There is obviously no possibility to use default values or leave them blank. Thats why one has the possibility to add preRelease and postRelease actions like scripts etc. However if the plugin would be slightly more intelligent that wouldn't be necessary imho.

enter image description here

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

Answers (1)

Bricktop
Bricktop

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:

  1. For each job in generation: Query your artifact repository for the latest version of the artifact created by the job (Sonatype Nexus for me)
  2. Generate the versions you want to display to a user (simply add the minor etc)
  3. Apply the version as the default-text to your string parameter in Job DSL (As shown here)
  4. Rerun the generation in a set interval, so the jobs most likely show the correct versions

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

Related Questions