Configure the job to enable releasing

On the job configuration page, enable the release build configuration under the Build Wrapper heading and add your required release version template string, release parameters, pre and post build steps that you need to complete a release.

Release Version Template

The release version template was added in version 1.7 of the release plugin. This parameter lets you define how the release plugin identifies the release of the project. This is done by building a parameter based template which is resolved at release time to a fully resolved string. For instance, the template can be: Release: ${releaseVersion}. This will instruct the release plugin to use the value of the parameter name releaseVersion to come up with the fully identifying string which will then be used as a description of the release build and as a tooltip on the release build icon on the historical build list.

Release Parameters

The release parameters let you define various parameters that are presented to the user when a release is requested. The list of available parameter types are the same as those available in the parameterized build option for Jenkins.

Build Steps

The build steps section is used to define arbitrary actions to run before and after the standard job build steps run. These are the same build steps offered as the build steps available in the free style job type.

In my experience, a release build typically requires pre-build steps of validating the project is releasable and bumping the version to the release version. After the build runs as usual, the post build steps are labeling the codebase and bumping the version to the next development version.

Executing a release

To run a release, click the Release icon from the job home page. This will bring you to the release details page where you will be prompted to fill in any parameters that you have defined (or the default RELEASE_VERSION and DEVELOPMENT_VERSION if there were no parameters defined). As seen above, these values are then available at job execution time in both the pre and post release steps as well as the normal build steps. Finally, click the schedule release build and the job is scheduled to run immediately, now including the execution of the pre and post build steps.

Viewing results

Once the build is complete, the release plugin automatically locks the build, preventing it from being automatically deleted and adds a release icon denoting it as a release build.

Supported Job Types

The release plugin supports the Maven2 and Free Style Job type

Recent Releases Portlet

The release plugin contributes a recent releases portlet that can be used in a Dashboard View.

This portlet shows the 5 most recent release builds in normal mode with a link that brings you to the build page and the version string. In the maximized mode, it shows the 50 most recent builds with additional detail. Additionally it offers an rss feed while in the maximized mode so that you can get notified of all release builds or all failing release builds.

Version 1.10 (7/21/2010)

Added new checkbox on job config page to allow the disabling of the automated marking of the build as keep forever

Fixed issue where if you had overlapping parameter names defined as release and build parameters, the default build parameter values were being used to resolve the release version template instead of the release parameter values.

Version 1.9 (11/15/2009)

Fixed issue where release plugin would prevent Jenkins from starting if dashboard view plugin was not installed (4845)

Fixed issue where recent releases portlet would throw NullPointer if a build was active

Version 1.8 (10/13/2009)

Version 1.7 (08/30/2009)

After sleeping on it, changed the implementation to use the release version template so that parameters types don't have to be aware of the release plugin in order to be used as a release version string.

Version 1.6 (08/29/2009)

Added new Release String Parameter that, when configured as a release parameter, will be used as the release value and the plugin will then set description and tooltip. (4022)

Version 1.5 (08/06/2009)

Changed form submission to use post instead of get. File upload parameters work now.

I took a brief look at the security a while ago but I didn't see a way for plugins to add new permissions. Do you have any pointers on this?

If the release process doesn't contain the normal build process, then you could just create a new job that contains exactly what your release steps are? This release plugin's value is that it is taking advantage of your job configuration including all the reporting plugins that you may have configured.

release:prepare -DscmCommentPrefix=[add:${ISSUE}] -DreleaseVersion=${RELEASE_VERSION} -DdevelopmentVersion=${DEVELOPMENT_VERSION} -Dtag=REL-${RELEASE_VERSION}
release:perform
release:clean
release:branch -DbranchName=rel-${DEVELOPMENT_VERSION} -DscmCommentPrefix=[add:${ISSUE}] -DupdateWorkingCopyVersions=false
I need to parametrized the ${ISSUE}
value but it is not working. Our SVN enforces strict comment standards due to which we need to provide an parametrized value

I took a quick look at how the SCM plugins generate the history. They call the build.getPreviousBuild method and ask for the build date. I would have to override the build class (or decorate it) in order for release plugin to inject a different build as the previous build. So it won't be too straightforward and could impact the stability of this plugin (as happened earlier) if I go down this path.

When you have the Descriptor Setting plugin enabled for the job, it overrides the Release plugin description. Would be nice if the Release plugin sets the description at the very end after the descriptor setting plugin has completed its job.

This might be a little tricky as the plugin is a BuildWrapper which Hudson core runs before the post build stuff. Also, I am not sure how Hudson orders plugins that execute during the same phase so it might not be guaranteed to get the description set properly. Maybe it would be better for the description plugin to not remove an existing description if one exists but just append its description after the existing one if any.

What would it involve to modify this plugin so the list of release steps matches the actions from the promotion plugin. The promotion plugin has a lot more actions such as svn tag, scp etc.. Would be great to have these for pre and post release steps. I'd be open to making the modifications

What would it involve to modify this plugin so the list of release steps matches the actions from the promotion plugin. The promotion plugin has a lot more actions such as svn tag, scp etc.. Would be great to have these for pre and post release steps. I'd be open to making the modifications

I have not used the promotion plugin and just quickly installed it and took a look around. I would think that it should not be too hard to get the larger list of actions that the promoted plugin offers (without taking a look at it). I'd be happy for you to contribute to the plugin in this manner. I think it would be a nice additional feature.

Unknown User (yun.zhi.lin@gmail.com)

Hi Peter,

While using your plugin, I was wondering would it be possible to make the parameters available to fields outside of the build properties.

i.e. Since this plugin is aimed at manual release, I want to be able to manually specify the CVS TAG to check out and build. But when I specify my RELEASE_VERSION Parameter in the CVS tag field in Source Code Management, it would throw an errors since it doesn't recognize the Parameter value.

My workaround would be to instead run CVS in Execution shell, and use RELEASE_VERSION as the check out there. But it would be much nice if the Release Parameters could be integrated with the standard Hudson Source Code Management.

Unknown User (lorand.somogyi)

I'm preparing Hudson for our team, and I'm really impressed by the features and plugins.

I was about to create a new plugin, when I ran into this plugin, and I think with a little stretching this plugin could provide a background for the next scenario:

We would like our releases to be ready ASAP. But on the other hand we need to generate Maven Site, which take a really long time (svnstat, pmd, findbugs, etc.). So I thought to decouple the release from the site rendering, and to execute site at idle time, - somewhere around 2am.

This plugin is now capable of executing mvn site after the release, but I would like to be able to:

schedule the build

bind the build to a node

That how site genertaion of sites (in my case) would not interfer our releases.

This sounds like a neat idea. The release plugin leverages the built in Hudson support for build parameters so you'd need to add support there. I'd suggest writing your own plugin that contributes a new parameter type. I did this myself with the Validating String Parameter Plugin.

This prevented all existing jobs from initializing in the hudson display. Backed it back and all was well again. Is this a localized problem or something more central to the new version? Let me know what you think. This is a useful plugin so I want to continue to use it's features. Thanks for your work.

Just looked again and it looks like since 1.337, BuildWrapper's are able to get the result state of the build. I'll make this change to treat builds that have failed as regular builds. I prefer this as well.

Unknown User (nathan.bragg@otda.state.ny.us)

Would it be possible to add different SCM credentials option much like how you tag a release in Hudson, or like the Maven 2 plugin allows you to do before you build the release? I would rather use this plugin than be tied to using the Maven2 project type, however because there is no option to input different SCM credentials at build time, it doesn't make it a viable candidate.

Is there any chance that this plugin can allow the definition of the release goals instead of using the jobs build goals and options? This would allow a single job to be repurposed for regular CI builds and for releases.

This plugin is almost exactly what I was looking for, so thanks for starters!

One feature that would be great is if there was a way to trigger a release build via passing parameters. In our environment, we have a bunch of independent projects which each have their own jobs. When we build a release, we need to build all of those projects as a release build. What I am thinking of is something similar to how a parameterized build works today, but the trigger would be something like:

which would then schedule the release build with the parameters passed in via the URL and could be triggered with the Parameterized Trigger Plugin

I have looked at the source, but I have not figured out how to implement that yet. I was wondering if instead of having ReleaseAction implement Action if I could have it extend hudson.model.ParametersAction , but I think it is going to be a lot more complicated than that.

In the mean time, I have modified the plugin be adding a field where you specify a boolean parameter which gets checked and if set true performs the release, but this does not really feels like the best solution.

Is there a way for downstream Jobs to also be marked as Released (with the Released icon)? For example, if I manually trigger JobA with the release button, I'd like JobB and JobC (both triggered from JobA) to be marked with the Released Icon (eg: they are variants of the same code).

First thing would be to change hudson.plugins.release.ReleaseWrapper.DescriptorImpl.isApplicable(AbstractProject<?, ?>) to include the IvyModuleSet class.
This should make it show up for an Ivy project in general. I don't know if any specific Ivy customizations are needed beyond that.

I did clone the plugin and tried to add the customization you suggested. Rather a lovely system the plugin-build-support that so nicely fires up Jenkins and allow me to stay in Eclipse and play around!

I made the dependency on Ivy project optional and loaded the class by name to make sure I would not impose Ivy project upon the harmless Jenkins-user ;) Hope I can keep it that way. ;)

The configuration now does show up in the Ivy project configuration. But now I have two issues:

The release number does not show in the builds-list to the left of my Ivy project

The release-step is not executed.

I presume I will have to do some jelly work to get 1 going. (The release number is stored in the 'Release' page when I hit 'Release' below the 'Build now' link.) But I'm not to fussy to live without it at the moment. Number 2 is rather mote important:

For number 2 I'm not sure where to go. The Ivy project is rather a fancy system that will create Jenkins jobs on-the-fly. And I'm not sure if the top-level job (the one you create manually) will allow me to do a step after all other sub-jobs have completed successfully. Are there any pointers?

We're running version 2.4.1 with the 1.565.1 core. In the "Promote builds when..." section of the project configuration page, the criterion labeled "If the build is a release build" occurs twice -- as the first AND second options in the "Criteria" list. Is anyone else seeing this?

The String parameters releaseVersion, targetServer and database are defined in the job. After having updated Jenkins to the higher version, the build doesn't produce the correct output. Downgrading Jenkins did help in getting the correct output again.