Release Plugin

Skip to end of metadata
Go to start of metadata

Plugin Information

Plugin ID release Changes In Latest Release
Since Latest Release
Latest Release
Latest Release Date
Required Core
Dependencies
2.4.1
Sep 27, 2013
1.481
dashboard-view (version:2.0, optional)
promoted-builds (version:2.0, optional)
maven-plugin (version:1.481)
javadoc (version:1.0)
Source Code
Issue Tracking
Maintainer(s)
GitHub
Open Issues
Peter Hayes (id: petehayes)
Usage Installations 2013-Apr 2453
2013-May 2493
2013-Jun 2485
2013-Jul 2586
2013-Aug 2522
2013-Sep 2606
2013-Oct 2686
2013-Nov 2738
2013-Dec 2662
2014-Jan 2760
2014-Feb 2813
2014-Mar 2921

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.

Additional plugin integration
Supports the Dashboard View with the Recent Releases portlet and the Promoted Builds Plugin with the Release build condition.

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 History

Version 2.4 (8/04/2013)

Version 2.3 (9/20/2012)

  • JENKINS-13422 Added release button column
  • Use package.png instead of package.gif to have transparent icons
  • Fixed release link being shown when project was disabled

Version 2.2 (9/13/2011)

  • Disabled auto-refresh when triggering a new release (thanks rseguy)
  • JENKINS-9705 Option to override regular build parameters during release

Version 2.1 (3/13/2011)

  • JENKINS-8816 Wrapped each build steps list in a f:block which seems to correct the drag and drop behavior
  • JENKINS-8829 Create permalinks for the latest release and latest successful release builds
  • Added i8n for promotion support
  • Added German translations

Version 2.0 (2/15/2011)

  • Migrated to Jenkins
  • If release build result is not at least unstable, then don't keep build forever.
  • Expand release version template using build variables as well as release parameters
  • Add support for the promoted build plugin to add a condition that the build must be a release build
  • Show all previous release parameters when scheduling a release build
  • Add post successful build steps and post failed build steps
  • Prefill release parameters with previous release builds parameters (supports text field, checkbox & select list (drop-down list) input types)

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)

  • 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 Jenkins' 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
plugin-listview-column plugin-listview-column Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Feb 11, 2009

    ricardo_go - 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

      Pete Hayes says:

      I'll try this out.

      I'll try this out.

  2. Feb 11, 2009

    spiddy - 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

      Pete 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

    shibug - 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

      Pete 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

        shibug - 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

        shibug - 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

    frohoff - says:

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

      Pete 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

      Pete 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

        Pete 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

    shibug - 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

      Pete 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

      Pete 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

      Pete 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

      Pete 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

      Pete 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

    nielsull - 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

      Pete 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

    bhoylman - 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

      Pete 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

          Pete 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

      Pete 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

    sanastos - 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

      Pete 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

        Pete 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

        Pete 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. Jul 04, 2011

    kinwah says:

    is there a way that only archive artifact if it is a release build?

    is there a way that only archive artifact if it is a release build?

    1. Jul 04, 2011

      Fred G says:

      Unfortunately not. This needs to be supported by core. I already opened a JIRA r...

      Unfortunately not. This needs to be supported by core.
      I already opened a JIRA request for a related issue: https://issues.jenkins-ci.org/browse/JENKINS-8392

      Hopefully I can work on it sometime soon.

  19. Sep 10, 2011

    Jim Scott says:

    Is there any chance that this plugin can allow the definition of the release goa...

    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.

    Thanks!

    1. Sep 10, 2011

      Pete Hayes says:

      This would be an enhancement.  Currently it always runs the regular build s...

      This would be an enhancement.  Currently it always runs the regular build steps, running the configured additional release steps before and after the build.  You can open a JIRA if you like.

  20. Sep 27, 2011

    Eric Meaney says:

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

    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:

    http://localhost/jenkins/<JOB_NAME>/release?<PRAMETER_NAME>=<PARAMETER_VALUE>

    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.

  21. Oct 17, 2011

    Jesse J says:

    Is there a way for downstream Jobs to also be marked as Released (with the Relea...

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

  22. Oct 18, 2011

    Wade S says:

    Is there a possibility of adding multi-config job support in this plugin? Thank...

    Is there a possibility of adding multi-config job support in this plugin?

    Thanks

  23. Nov 08, 2011

    gkephorus - says:

    Can support for Job Type 'Ivy project' be added? How hard would that be. I do ha...

    Can support for Job Type 'Ivy project' be added? How hard would that be. I do have some Java programming skill and am not afraid of GitHub. Can anyone give me any pointers?

    1. Nov 08, 2011

      Fred G says:

      Please open a JIRA feature request for this, so it doesn't get lost. Apart from...

      Please open a JIRA feature request for this, so it doesn't get lost.

      Apart from that, feel free to fork the release-plugin from https://github.com/jenkinsci/release-plugin and open a pull request when you have it working.

      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.

      1. Nov 09, 2011

        gkephorus - says:

        Thanks. A JIRA feature request has been added: JENKINS-11659. I did clone the p...

        Thanks. A JIRA feature request has been added: JENKINS-11659.

        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:

        1. The release number does not show in the builds-list to the left of my Ivy project
        2. 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?

  24. Oct 15, 2013

    selvakumar periasamy says:

    It is possible to execute the release build from command line. For example:...

    It is possible to execute the release build from command line. For example:(It works for me)

    Normal build: curl -X POST http://jenkins/job/test/build -d token=zorn --data-urlencode json="{\"parameter\": [{\"name\": \"var1\", \"value\":\"val1\"}], \"\": \"\"}"

    Release Build: curl -X POST http://jenkins/job/test/release/submit -d token=zorn --data-urlencode json="{\"parameter\": [{\"name\": \"var1\", \"value\":\"val1\"}], \"\": \"\"}"