Release Plugin

Plugin Information

Plugin ID release
Latest Release 2.3-h-1
Latest Release Date Sep 26, 2012
Sources Github
Support Eclipse Hudson Forum
Issue Tracking Eclipse Bugzilla

This plugin adds the ability to wrap your job with pre- and post- build steps which are only executed when a manual release build is triggered.

New
Now supporting the Dashboard View with the Recent Releases portlet!


Version 1.2 of the release plugin changed the release plugin usage, though it maintained backwards compatibility.  See the archived release plugin documentation for the old configuration details

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 Hudson.

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.  As of release 1.11, you can now specify steps to run only after a successful build (a result of at least unstable) and steps to run only after a failing build.

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 History

Version 1.11 (1/30/2011)

  • If release build result is not at least unstable, then don't keep build forever.
  • Add post successful build steps and post failed build steps
  • Enabled clicking of previous release build parameters to use as current release build parameters (thanks fredg for the contribution)
  • Set the release version as the build's display name instead of description

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 Hudson 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)

  • Added support for Dashboard View plugin by adding Recent Releases portlet

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.

Version 1.4 (05/16/2009)

  • Fixed regression issue introducing release parameters (3690)

Version 1.3 (05/11/2009)

  • Fixed regression due to maven plugin change (3628)

Version 1.2 (05/1/2009)

  • Added support for user supplied release parameters leveraging Hudson's parameter capability (3370)

Version 1.1 (03/26/2009)

  • Add permissions on triggering a release
  • Fixed issue where parameters were not being resolved
  • Captured release parameters as build parameters which can now be viewed via build parameters link

Version 1.0 (02/10/2009)

  • Initial release

Labels:

plugin-buildwrapper plugin-buildwrapper Delete
supports-dashboard-view supports-dashboard-view Delete
tier3-hudson-plugin tier3-hudson-plugin Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Feb 11, 2009

    Ricardo Oliveira says:

    I believe this could be useful also for multi-configuration (matrix) projects. T...

    I believe this could be useful also for multi-configuration (matrix) projects.
    Thanks for the plug-in

    1. Feb 11, 2009

      Peter Hayes says:

      I'll try this out.

      I'll try this out.

  2. Feb 11, 2009

    Dimitris Kapanidis says:

    Nice plugin, Some feedback: - It would be nice to have the possibility to ...

    Nice plugin,

    Some feedback:

    - It would be nice to have the possibility to configure security issues about the Release button independent from the Build button.

    - The release process may not contain the normal build process but a different one (maybe add a button to disable the normal build process during release).

    thanks for the plugin

    1. Feb 11, 2009

      Peter Hayes says:

      I took a brief look at the security a while ago but I didn't see a way for plugi...

      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.

  3. Feb 19, 2009

    Shibu Gope says:

    How do I provide more parameters?  These are my steps below: release:prepa...

    How do I provide more parameters?  These are my steps below:

    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

    1. Feb 19, 2009

      Peter Hayes says:

      The plugin only supports 2 input fields, development version and release version...

      The plugin only supports 2 input fields, development version and release version.  Could you perhaps use a comment called branching for development of rel-${DEVELOPMENT_VERSION}

      1. Feb 20, 2009

        Shibu Gope says:

        The best would be if this plugin follows the maven-release plugin parameter type...

        The best would be if this plugin follows the maven-release plugin parameter types.  I like the way Continuum implemented it.

      2. Mar 27, 2009

        Shibu Gope says:

        How about asking for the comment at runtime?  similarly like asking for the...

        How about asking for the comment at runtime?  similarly like asking for the release version and development version.

  4. Feb 19, 2009

    Chris Frohoff says:

    Looks great, though it would be great if this could natively support the maven r...
    1. Feb 19, 2009

      Peter Hayes says:

      I think that the Sonatype guys are working on Maven2 release supportfor Hudson.&...

      I think that the Sonatype guys are working on Maven2 release supportfor Hudson. 

  5. Feb 20, 2009

    huimies says:

    This plugin is great, but one feature would make it awesome. If changes would b...

    This plugin is great, but one feature would make it awesome.

    If changes would be collected from last release build to current release build so that in changes view you could see a complete changelog between releases.

    1. Mar 26, 2009

      Peter Hayes says:

      This would be very cool and something that I would be interested in as well.&nbs...

      This would be very cool and something that I would be interested in as well.  I will see if there is some way I can pass the date Hudson uses to generate a change log.

      1. Mar 26, 2009

        Peter Hayes says:

        I took a quick look at how the SCM plugins generate the history.  They call...

        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.

  6. Feb 20, 2009

    Shibu Gope says:

    One more problem I found: When you have the Descriptor Setting plugin enabled f...

    One more problem I found:

    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.

    1. Mar 26, 2009

      Peter Hayes says:

      This might be a little tricky as the plugin is a BuildWrapper which Hudson core ...

      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.

  7. Mar 20, 2009

    Robert James says:

    I have a slight problem. I'm running Hudson 1.292 inside of tomcat 5.5 as a Wind...

    I have a slight problem. I'm running Hudson 1.292 inside of tomcat 5.5 as a Windows Service and trying use the release plugin. Here's the problem:

    I have targets in pre and post release that I want to use

    -Dversion=${RELEASE_VERSION}

    The problem is this my version property for the ant build gets set literally to

    ${RELEASE_VERSION}

    and not 2.1.1 or similar.

    1. Mar 26, 2009

      Peter Hayes says:

      Fixed in 1.1

      Fixed in 1.1

  8. Apr 04, 2009

    Colin Goudie says:

    What would it involve to modify this plugin so the list of release steps matches...

    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

  9. Apr 04, 2009

    Colin Goudie says:

    What would it involve to modify this plugin so the list of release steps matches...

    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

    1. Apr 30, 2009

      Peter Hayes says:

      Sorry for not noticing this post for a long time. I have not used the promotion...

      Sorry for not noticing this post for a long time.

      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.

  10. Jul 15, 2009

    Yun Zhi Lin says:

    Hi Peter, While using your plugin, I was wondering would it be possible to make...

    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.

    Cheers

    1. Oct 13, 2009

      Peter Hayes says:

      I would think there is some way to do this.  Have you looked at the Hudson ...

      I would think there is some way to do this.  Have you looked at the Hudson source code to see how this might be possible.  I'm pretty sure this would require a change to the Hudson core to accomplish.

  11. Aug 26, 2009

    Lorand Somogyi says:

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

    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.

    What do you think? 

    I'm ready to contribute.

    Regards, Lorand.

    1. Oct 13, 2009

      Peter Hayes says:

      I would just create an additional Hudson job that handles the site generation.&n...

      I would just create an additional Hudson job that handles the site generation.  See this article on suggestions for breaking up a long running build.

  12. Sep 30, 2009

    Niels Ull Harremoes says:

    Would it be possible to enable GString parsing in the parameter default value - ...

    Would it be possible to enable GString parsing in the parameter default value - possibly enabled as a checbox to retain backwards compatibility?

    I would like to set the default value to include the current date as in "Release_2009_09_30" by setting the default string to

    "Release_${new SimpleDateFormat('yyyy-MM-dd').format(new Date())}"

    But the user should still be able to edit this before starting the release.

    1. Oct 13, 2009

      Peter Hayes says:

      This sounds like a neat idea.  The release plugin leverages the built in Hu...

      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.

  13. Oct 15, 2009

    Bruce W. Hoylman says:

    Hello -- I updated the Release plugin from v1.7 -> v1.8.  U...

    Hello --

    I updated the Release plugin from v1.7 -> v1.8.  Upon restarting my hudson instance the following errors were encountered:

    WARNING: Failed to load a project
    java.lang.NoClassDefFoundError: hudson/plugins/release/dashboard/RecentReleasesPortlet
            at java.lang.Class.getDeclaringClass(Native Method)
    ...

    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.

    Peace.

    1. Oct 15, 2009

      Peter Hayes says:

      Sorry about that.  I failed to test the release plugin with an instance of ...

      Sorry about that.  I failed to test the release plugin with an instance of Hudson that did not have the Dashboard View plugin installed. I'll have to cut another release.

      1. Oct 15, 2009

        newguy says:

        I got that error too. After installing Release plugin 1.8 hudson 1.328 will neve...

        I got that error too. After installing Release plugin 1.8 hudson 1.328 will never start again. There are tons of errors in the log.

        I think this is definitely caused by the relationship between Dashboard View plugin and Release plugin. After I installed Dashboard View plugin everything goes smoothly with Release plugin.

        1. Nov 15, 2009

          Peter Hayes says:

          Release 1.9 addresses this issue.

          Release 1.9 addresses this issue.

    2. Oct 20, 2009

      Anthony Chamas says:

      I needed to manually remore release/, release.hpi in .hudson/plugins folder to ...

      I needed to manually remore release/, release.hpi in .hudson/plugins folder to have hudson work again.
      Cheers,
      /a

  14. Dec 13, 2009

    Max Khon says:

    Could you add support for multiconfiguration projects, please?

    Could you add support for multiconfiguration projects, please?

    1. Dec 13, 2009

      Peter Hayes says:

      Could you open an enhancement request describing the use case that you are inter...

      Could you open an enhancement request describing the use case that you are interested in?

  15. Dec 17, 2009

    Stephen Anastos says:

    The release template does not seem to like my parameter, which has a dot in it. ...

    The release template does not seem to like my parameter, which has a dot in it. After a release, below the build summary the tag reads

    'Release #${project.version}'

    Using

    ${projectVersion}

    works fine, but

    ${project.version}

    does not. I tried with release plugin v1.7 and v1.9 and hudson v1.327.

  16. Aug 23, 2010

    Johannes Fischer says:

    Is it possible that a failed build would not be labeled as a Release build (lock...

    Is it possible that a failed build would not be labeled as a Release build (locked, published in dashboard, etc) but just treated as a normal build failure?How do I configure this?

    If this is currently not supported it would be great to have it in one of the next releases.

    Thanks a lot for this great plugin.

    1. Jan 17, 2011

      Peter Hayes says:

      When I looked at this a while back, it was not possible using the BuildWrapper e...

      When I looked at this a while back, it was not possible using the BuildWrapper extension point to detect if a build failed or not. 

      1. Jan 17, 2011

        Peter Hayes says:

        Just looked again and it looks like since 1.337, BuildWrapper's are able to get ...

        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.

      2. Jan 17, 2011

        Peter Hayes says:

        As I'm looking at this, I think I should keep the registration that this was sup...

        As I'm looking at this, I think I should keep the registration that this was supposed to be a release build, but I won't automatically mark the build to keep forever.

  17. Jan 14, 2011

    Nathan Bragg says:

    Would it be possible to add different SCM credentials option much like how you t...

    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.

  18. Oct 31, 2011

    Mladen Markov says:

    And how can I delete builds which have been locked? Maybe a dump question, but I...

    And how can I delete builds which have been locked?
    Maybe a dump question, but I couldn't find this anywhere...