Skip to end of metadata
Go to start of metadata

Plugin Information

View promoted builds on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

This plugin allows you to distinguish good builds from bad builds by introducing the notion of 'promotion'.Put simply, a promoted build is a successful build that passed additional criteria (such as more comprehensive tests that are set up as downstream jobs.) The typical situation in which you use promotion is where you have multiple 'test' jobs hooked up as downstream jobs of a 'build' job. You'll then configure the build job so that the build gets promoted when all the test jobs passed successfully. This allows you to keep the build job run fast (so that developers get faster feedback when a build fails), and you can still distinguish builds that are good from builds that compiled but had runtime problems.

Another variation of this usage is to manually promote builds (based on instinct or something else that runs outside Jenkins.) Promoted builds will get a star in the build history view, and it can be then picked up by other teams, deployed to the staging area, etc., as those builds have passed additional quality criteria. In more complicated scenarios, one can set up multiple levels of promotions. This fits nicely in an environment where there are multiple stages of testings (for example, QA testing, acceptance testing, staging, and production.)

Promotion Action

When a build is promoted, you can have Jenkins perform some actions (such as running a shell script, triggering other jobs, etc. — or in Jenkins lingo, you can run build steps.) This is useful for example to copy the promoted build to somewhere else, deploy it to your QA server. You can also define it as a separate job and then have the promotion action trigger that job.

Do not rely on files in the workspace

The promotion action uses the workspace of the job as the current directory (and as such the execution of the promotion action is mutually exclusive from any on-going builds of the job.) But by the time promotion runs, this workspace can contain files from builds that are totally unrelated from the build being promoted.

To access the artifacts, use the Copy Artifact Plugin and choose the permalink.

Usage

To use this plugin, look for the "Promote builds when..." checkbox, on the Job-configuration page. Define one or a series of promotion processes for the job.

Then, after the promotion processes have been added and another build is run, a 'Promotion Status' menu item will be added to the new build's menu options. Note that this means that builds run before this point cannot be promoted.

How might you use promoted builds in your environment? Here are a few use cases.

Artifact storage -- you may not want to push an artifact to your main artifact repository on each build. With build promotions, you can push only when an artifact meets certain criteria. For example, you might want to push it only after an integration test is run.

Manual Promotions - You can choose a group of people who can run a promotion manually. This gives a way of having a "sign off" within the build system. For example, a developer might validate a build and approve it for QA testing only when a work product is completed entirely. Then another promotion can be added for the QA hand off to production.

Aggregation of artifacts - If you have a software release that consists of several not directly related artifacts that are in separate jobs, you might want to aggregate all the artifacts of a proven quality to a distribution location. To do this, you can create a new job, adding a "Copy artifacts from another job" (available through Copy Artifact plugin") for each item you want to aggregate. To get a certain promotion, select "Use permalink" in the copy artifact step, then your promoted build should show up in the list of items to copy.

Notes

On Downstream Promotion Conditions

One of the possible criteria for promoting a build is "When the following downstream projects build successfully", which basically says if all the specified jobs successfully built (say build BD of job JD), the build in the upstream will be promoted (say build BU of job JU.)

This mechanism crucially relies on a "link" between BD and BU, for BU isn't always the last successful build. We say "BD qualifies BU" if there's this link, and the qualification is established by one of the following means:

  1. If BD records fingerprints and one of the fingerprints match some files that are produced by BU (which is determined from the fingerprint records of BU), then BD qualifies BU. Intuitively speaking, this indicates that BD uses artifacts from BU, and thus BD helped verify BU's quality.
  2. If BU triggers BD through a build trigger, then BD qualifies BU. This is somewhat weak and potentially incorrect, as there's no machine-readable guarantee that BD actually used anything from BU, but nonetheless this condition is considered as qualification for those who don't configure fingerprints.

Note that in the case #1 above, JU and JD doesn't necessarily have to have any triggering relationship. All it takes is for BD to use some fingerprinted artifacts from BU, and records those fingerprints in BD. It doesn't matter how those artifacts are retrieved either — it could be via Copy Artifact Plugin, it could be through a maven repository, etc. This also means that you can have a single test job (perhaps parameterized), that can promote a large number of different upstream jobs.

Note that after installing this plugin and configuring a promotion process, the option to promote the build will not be available for builds run before the promotion process was configured.

Available Environment Variables

The following environment variables are added for use in scripts, etc. These were retrieved from github here.

  • PROMOTED_USER_NAME - the user who triggered the promotion
  • PROMOTED_USER_ID - the user's id who triggered the promotion
  • PROMOTED_JOB_FULL_NAME - the full name of the promoted job

Changelog

Version 3.2 (JUN 4, 2018)
  • PR #116 -  Show the full display name of runs in promoted build parameters
Version 3.1 (Mar 12, 2018)
  • JENKINS-40803 - Prevent infinite loop when promoting a build while the Config File Provider Plugin is installed. 
Version 3.0 (Feb 26, 2018)
  • (error)SECURITY-746 - Make permissions consistent for Approve, Re-Execute, and Force promotion actions
    • Users with just the Promotion/Promote permission are no longer allowed to re-execute or force promotions with a manual condition that specifies a list of users, unless the user is on that list

    • Users specified in a manual promotion condition are now allowed to force this promotion

    • Administrators are now able to approve any promotion with a manual condition

Compatibility Notes:

  • This change alters the behavior of the Plugin in some conditions, jobs may require reconfiguration. 
  • Table below shows the permission changes. Legend:
    • Cells with bold red text - indicate combinations, which revoke dangerous permissions
    • (manual condition) - Action 

Jobs which have no Manual Promotion Condition 

Authorized actions

Granted Permissions
Overall/AdministerPromotion/PromoteUser/group in the manual condition user listJob/Read

Approve

N/AN/AN/AN (new)
Re-executeYYN/AN (new)
ForceYYN/AN

Jobs which have Manual Promotion Conditionwithout users/groups defined:

Authorized actions

Granted Permissions
Overall/AdministerPromotion/PromoteUser/group in the manual condition user listJob/Read

Approve

YYN/AN (new)
Re-executeYYN/AN (new)
ForceYYN/AN

Jobs with a Manual Promotion Condition with a non-empty set of users/groups :

Authorized actions

Granted Permissions
Overall/AdministerPromotion/PromoteUser/group in the manual condition user listJob/Read
ApproveY (new)NYN (new)
Re-executeYN (new)YN (new)
ForceYN (new)Y (new)N

 

Version 2.31.1 (Feb 13, 2018)
  • (error) JENKINS-49433 - Prevent NullPointerException in JobDSL when omitting the evenIfUnstable argument
    • Affected JobDSL methods: selfPromotion()parameterizedSelfPromotion()downstream()
  • (error) JENKINS-48634 - Prevent ClassCastException when running promotion from a status page with empty forms
Version 2.31 (Oct 23, 2017)
Version 2.30 (Oct 19, 2017)
  • (info) PR #106 - Update Jenkins core requirement to 1.625.3
  • (info) PR #106 - Update Maven plugin requirement to 3.0 and cleanup issues in library dependency conflicts
  • (error) JENKINS-22068 - Fail promotion builds instead of hanging when a promotion is built/rebuilt directly 
Version 2.29.1 (Sep 7, 2017)
  • (info) JENKINS-37368 - Improve performance of DownstreamPass promotion condition listener logic
Version 2.29 (Jun 16, 2017)
  • (info) PR #103 - Update the target core baseline to 1.609.3 
  • (plus) JENKINS-29586 - Add support for ANSI color output in console
  • PR #102 - Fix link to the Fingerprint Wiki Page
Version 2.28.1 (Jan 31, 2017)
  • (error) JENKINS-40552 - Prevent possible deadlock between JobPropertyImpl and PromotionProcess
Version 2.28 (Nov 18, 2016)
  • (error) JENKINS-29358 - Fix the sort order of the Promotion History
  • (info) JENKINS-36623 - Fix test runs against the 1.651.3 core (Plugin compatibility tester)
  • (info) JENKINS-39362 - Fix the binary compatibility issues in test runs by getting rid of mockito-all
Version 2.27 (May 25th, 2016)
  • (error) JENKINS-34826 - Make the plugin compatible with SECURITY-170 fix in Jenkins 1.651.2+ and 2.3+
  • (error) PR #91 - Prevent exceptions on startup if the optional JobDSL plugin is missing
  • (info) PR #90 - Improve the workspace allocation performance
Version 2.26 (May 9th, 2016)
  • (plus) JENKINS-29776 - Add Job DSL support for Promoted Builds Plugin
  • (plus) JENKINS-33147 - PROMOTED_TIMESTAMP used to show the UTC timestamp instead of the local JVM one. Behavior is configurable now
  • (plus) PR #76 - Allow hiding promotion processes based on a parameter value
  • (info) PR #89 - Migration to the new Jenkins Plugin parent POM
  • (error) PR #87 - Fixes of minor issues discovered by FindBugs
  • (error) JENKINS-34204 - Fix minor issues in Job DSL support discovered during the local snapshot testing (not a regression)
Version 2.25 (Feb 19th, 2016)
  • (plus) JENKINS-32993 - Expose the PROMOTED_TIMESTAMP variable in promotion processes
  • (plus) PR #75 - Add support for running promotions on inheritance projects
  • (error) JENKINS-31908 - Sort Promotions in UI by Number instead of customization ID
  • (error) JENKINS-31406 - Broken layout of promotion status pages in 1.625+
Version 2.24.1 (Dec 17th, 2015)
Version 2.24 (Nov 25th, 2015)
  • (error) JENKINS-13751 - Promotion process should provide the project's SCM to promotion steps (reverted in 2.24.1)
  • (error) JENKINS-31356 - The plugin should consider approvers in the re-execution action
  • (error) PR #72 - Fix exception if somebody calls PromotionProcess::isFingerprintConfigured()
  • (info) JENKINS-29793 - Provide parameters from manual approval on all promotions
  • (plus) JENKINS-27716 - Support disabling the promotion jobs in jenkins-1.585+
Version 2.23.1 (Nov 2nd, 2015)
  • (error) JENKINS-31320 - Make the plugin compatible with breaking UI changes in Jenkins 1.619+
Version 2.23 (Sept 15th, 2015)
Version 2.22 (Aug 25th, 2015)
  • (error) JENKINS-25011 - Fix the Folders support in Promoted builds parameter
    • Now there is a support of global and relative addressing to builds ('.' and '..' markers are supported)
    • See the built-in documentation for more details
    • The change alters the default behavior
  • (error) JENKINS-7739 - Recursively evaluate downstream projects in DownstreamPassCondition
  • (plus) JENKINS-3549 - Promotion Status column (last promotions for each type)
  • (plus) JENKINS-3549 - Last Build Promotion Status column
  • (plus) JENKINS-16063 - Inject PROMOTED_USER_ID variable into the build
  • (info) FindBugs cleanup (potential NPEs, concurrency, etc.)

Warning!

The fix for JENKINS-25011 changes the default behavior for paths without an explicit absolute/relative address specification (e.g. project="myProject"). By default it will resolve relative paths and then falls back to global paths. If you have "myProject" within a folder and on the top level, another project may be returned after the plugin update. In order to restore the legacy behavior, use the hudson.plugins.promoted_builds.util.ItemPathResolver.enableResolutionAgainstRoot Boolean system property

Version 2.21 (Apr 7, 2015)
  • issue #24782 Prevent phantom builds from being scheduled when PromotionProcesses are built directly.
Version 2.20 (Feb 16, 2015)
  • issue #20492 partial fix, show re-execute button unconditionally
  • fix an NPE in getBuilds() when projectName is incorrect
  • added support for rebuild plugin
Version 2.19 (Oct 10, 2104)
  • Prevent log file being cluttered with permission exceptions when users have Item.EXTENDED_READ but not Item.CONFIGURE
Version 2.18 (Aug 25, 2014)
Version 2.17 (Mar 5, 2014)
Version 2.16 (Mar 5, 2014)
  • Added PROMOTED_USER_NAME environment variable (issue #16063)
  • Fixed a couple of typos
  • Fixed repeated exception being thrown when installed with literate plugin.
Version 2.15 (Jan 28, 2014)
Version 2.14
Version 2.13
  • Added PROMOTED_JOB_FULL_NAME environment variable (JENKINS-18958)
Version 2.12 (Aug 20, 2013)
  • Expose promotion information via the REST API
  • Prevent duplication of promotion processes when creating promotion processes from other plugins
Version 2.11 (Jun 09, 2013)
  • Fix for an NPE, and diagnosis for another.
  • Reduced plugin size by eliminating unnecessarily bundled library.
Version 2.10 (Mar 30, 2013)
Version 2.9 (Mar 25, 2013)
  • New promoted build parameter that can be used to select builds that have been promoted
  • Fixed file parameter on ManualApproval not correctly uploading the file
Version 2.8 (Oct 30, 2012)
Version 2.7 (Sep 26, 2012)
  • Added a trigger that allows projects to listen to promotions happening in other projects
  • PROMOTE permission can be used in project matrix-based security (JENKINS-14890)
  • Downstream jobs textbox is now auto-complete-capable (JENKINS-14560)
Version 2.6.2 (Aug 6, 2012)
  • Fix manual promotion of maven project and matrix project (JENKINS-13631, JENKINS-13472)
  • Fix 404 when clicking the promotion's progress bar to view console output (pull-20)
Version 2.6.1 (Jul 2, 2012)
  • Fix preventing setting "Restrict where this project can be run" (JENKINS-14197)
Version 2.6 (Jun 21, 2012)
Version 2.5 (Apr 12, 2012)
  • Improved hierarchical project support
Version 2.4 (Nov 3, 2011)
  • Fixed a possible NPE that fails the promotion (JENKINS-11609)
  • Added Promotion History per Promotion Process at Project's Promotion Status page (JENKINS-10448)
Version 2.3.1 (Oct 14, 2011)
  • Don't run promotionProcess that are disabled (JENKINS-10423)
  • Manual approvement causes an NPE if project name or promotion name contains URI-unsafe chars (JENKINS-11122)
Version 2.3 (Aug 9, 2011)
  • Modified the self-promotion condition so that it does not trigger for builds which are a failure. Also it is now configurable whether to self-promote for unstable builds. (JENKINS-10250)
Version 2.2 (Jul 8, 2011)
  • Added a new promotion condition that immediately promotes itself.
Version 2.1 (May 4, 2011)
  • failed to Re-execute promotion if promotion builds plugin is disabled (JENKINS-9588).
  • promote plugin should provide ability to select slave node to run (JENKINS-9260).
  • Fix for NPE when promoting a build with a custom workspace (JENKINS-9254).
  • Fixed a problem where removing a promotion process leaves broken image links in the build history.
  • Fixed a problem where deleting and recreating the promotion process with different case (abc vs ABC) can result in weird behavior on Windows.
Version 2.0 (Mar 5 2011)
  • If a promotion criteria is met but the promotion fails, change the icon to represent that.
  • Exposed the job name and the build number of the promotion target to the promotion process (PROMOTED_JOB_NAME and PROMOTED_NUMBER.)
  • If the build is parameterized, expose that to the promotion process as well
  • Added a new promotion criteria where a promotion in upstream promotes a downstream build.
  • Fully implemented manual approval with user / group permissions and display Approve button on promotion page (no longer need to allow force promotion to all)
  • New promotion action to mark the promoted build as keep forever
Version 1.11 (Jan 31 2011)
Version 1.10 (Sep 28 2010)
  • Promotion processes are now recognized as permalinks.
Version 1.9 (Jun 9 2010)
  • If fingerprints are not available, use the upstream/downstream triggering information to determine the relationship as a fallback.
Version 1.8 (Jun 5 2010)
  • Add the possibility to choose a different color for the star icon, to be able to differenciate the various promotion processes
Version 1.7 (Mar 29 2010)
  • Use JDK configured for project when running promotions (JENKINS-3526)
  • Select node for running promotions from label configured for project (JENKINS-4089) (does not yet run on exact node where promoted build ran, unless project is tied to a single node)
  • Show most-recent first in promotion history tables (JENKINS-6073)
Version 1.6 (Dec 30 2009)
Version 1.5 (Aug 17 2009)
  • Updated to work with Jenkins 1.320
Version 1.4 (May 21 2009)
  • Re-doing a release as 1.3 had never shown up in the update center.
Version 1.3 (May 11 2009)
  • Expose environment variable 'PROMOTED_URL' that points to the URL of the build that's being promoted (report)
  • Internal modernization.
Version 1.2 (Mar 25 2009)
  • Updated to work with the current Jenkins
Version 1.1 (Feb 20 2009)
  • Fixed a problem where Jenkins may issue the same warning multiple times for the same configuration problem (report)
  • SVN Tagging is now a permitted promotion step
  • Promotion now fails if any actions are not performed (JENKINS-2597)
  • Improved logging of promotion build process so users can see what succeeded and what failed
  • Promotion action to build another project no longer does nothing (JENKINS-1765)
  • Added "Promotion History" pane to the PromotedBuildAction page (JENKINS-2794)
  • Fixed 404 for last failed link while promotion build occuring (JENKINS-2578)PROMOTED_URL

137 Comments

  1. Unknown User (bilabee)

    I am using promotion to promote a compilation project and build an installer project once the compilation project is promoted (UTC promotion criteria).  Is there a way to sync the upstream (compilation) project build number with the action project build number?  The have to be the same b/c some of the c++ header files and property files contain build number info.

    Thanks. 

    1. Unknown User (barnash)

      I don't know if it's still relevant, but I needed to use build number and the job name of the original job that I'm promoting.

      I created a small shell script that extracts it from a weird place in hudson home directory.

      JOB_NAME=`echo $JOB_NAME | sed s/promotion/promotions/`
      OUTPUT=`grep Promoting "$HUDSON_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER/log"`
      # The output will be something like: Promoting myJob #456
      ORIG_JOB_NAME=`echo $OUTPUT | awk '{print $2}'`
      BUILD_NUMBER=`echo $OUTPUT | awk '{print $3}' | cut -b 2-`
      

      This will probably won't work if on slaves and will have to change somehow, but it works really great for me when I only have one master box.

      It will probably be a good idea just to give some access to a variables like $ORIG_JOB_NAME and $ORIG_BUILD_NUMBER from the plug-in code.

  2. Unknown User (sfinley@phtcorp.com)

    Is there a way to set who has the right to promote a build? I am using it with the only when manually approved option. I am also using hudson matrix based security. It looks like the only way someone can promote is if they have administer privileges.

    Thanks

  3. I am attempting to configure a Hudson Job to use the Build Promotion Plugin. I want to manually promote a build.  The onscreen help indicates that selecting the criteria "Only when manually approved" provides a push button method to manually promote the build. I have been unable to find the button or link called "force promotion" once I have enable this criteria.

     Can anyone tell me if this feature is implemented and if so where do I find the "force promotion" button.
     Thank you

    1. Unknown User (peter@centgraf.net)

      To find the button:

      1. Go to a project that has a promotion process defined.

      2. Make sure that a build has occurred after the promotion process was defined.  (If not, trigger a build now.)

      3. Go to the page for a specific build (one that happened after the promotion process was defined).

      4. Click on the "Promotion Status" link in the menu on the left.

      5. Under the section for the specific promotion process, there will be a button on the far right.

      1. For the Force Promotion capability, you need to enable this at the Jenkins level via global permissions.

  4. Unknown User (steve.leach@estafet.com)

    It would be great if the promotion actions included the ability to run a target from the project's ant script.  This would let me have a "build" target and a "promote" target, for example, with the build target running automatically whenever there is a code change, and the "promote" target run manually.

  5. This plugin fails for me with Hudson 1.284 when trying to configure a promotion.  Below is the stack trace snippet:

    Failed to parse form data. Please report this probelm as a bug JSON=
    {"..."}
    net.sf.json.JSONException: null object at net.sf.json.JSONObject.verifyIsNull(JSONObject.java:2498) at net.sf.json.JSONObject.getString(JSONObject.java:1842) at hudson.plugins.promoted_builds.JobPropertyImpl.(JobPropertyImpl.java:67) at hudson.plugins.promoted_builds.JobPropertyImpl.(JobPropertyImpl.java:37) at

     

  6. Problem still exist with 1.285

  7. Great plugin but have found a couple of issues -

    1. lt will not allow me to add more than one promotion process at a time, I get the following error - Failed to parse form data. Please report this probelm as a bug followed by a a JSON string
    2. When adding a new promotion process, the newly added process will not allow me to add any actions until the configuration has been saved and reloaded.
    3. When copying an existing build configuration, the promotion section is not copied.

    Any assistance would be gratefully received.

    1. Unknown User (peter@centgraf.net)

      I second the request to copy existing promotions when copying a job.  This would be handy when we move from trunk to a branch during the endgame of a release.

  8. Where can I find Version 1.3? I see the changelog, but I can't find it on the downloads page.

  9. Unknown User (ryan.ramage@gmail.com)

    I am trying to get a build promoted using this tool. One question I have is around the fingerprints of the artifacts. Does the set of artifacts have to be equivalent on both projects (the upstream and downstream)? Or can it be an intersection of the two sets of artifacts?

  10. Unknown User (musoccer)

    There is a problem with this plugin when trying to promote a build with the "Invoke top-level Maven targets" action on a build that is tied to a specific node.  The promotion process is not obeying the fact that the project build was tied to a specific node, so when it tries to invoke the maven target, it does so on a different node.  This node obviously does not have the project directory checked out there, so it fails with a "no such file or directory" error.

  11. Right now, the new version 1.5 isn't available via hudson's plugin manager or the download area of the hudson site. If you try to run hudson 1.320 with the promoted-builds plugin, you get HTTP 500 errors because of some tags using old bindings. I guess the publishing process didn't suceed for the new version?

  12. Unknown User (capitaine.banane@gmail.com)

    I have a problem, because all the parameters I set for the job are null when I promote a build with a promotion that re-use these paremters.

    1. cava, were you able to resolve this by any change? I am also having the same issue. I am able to pass things like JENKINS_HOME and PROMOTE_ID but not the custom parameters I have created for my build. Am i missing something here? Any help is much appreciated?

  13. Unknown User (girafi@gmail.com)

    I would love to have the promoted builds available with a permanent URL just like the permalinks for the latest successful, latest stable build a.s.o. 

    e.g. myjob/qaBuild, myjob/qaApproved ...

    Maybe I just didn't find it in the documentation or is it not yet implemented?

  14. Unknown User (nhahn)

    Great plugin - my department has been using with this Hudson for almost a year now.  Anyways, with my department growing it now makes sense for us to use the mutli-configuration job.  Is there any chance support for the job can be added?

  15. A great feature would be to prompt the user for a pre-defined password (which will be configurable in the promotion build step) in order to release a version.

  16. Unknown User (gillesquerret)

    Version 1.6 changelog says that there's a fix for running on slave node. However I'm still having a problem when manually triggering a promotion. This project is bound to a specific node, but the Ant task executed by the promotion is always executed on the master node (and failing because it doesn't find the workspace). Is this the standard behavior, or is there still a bug ?

    1. Unknown User (gillesquerret)

      In fact, I just had to recreate the job to make it work.

  17. Unknown User (jhendric)

    This is a great addon. I am now using it and so far it has caught on well with my users to the point I now have a new requirement. I need to publish the promoted build artifact to the scp server. I tried a few tests and it moves just the artifacts in the current build even though the user promotes a build 2 or 3 generations earlier.

    How do I set it up to pull the correct build generation?

    Thanks

    1. Unknown User (adamb)

      I second this request. It would be extremely helpful to be able to deploy an archived artifact.

    2. I was looking at a hack to do this:

      • execute a shell:
        rm -fr hudson-promotion
        mkdir -p hudson-promotion
        cd hudson-promotion
        wget --accept tgz,pkg --no-directories --restrict-file-names=windows --recursive --level 1 -erobots=off --relative ${PROMOTED_URL}artifact/
        
        • our targets end in tgz or pkg
        • --restrict-file-names and --no-directories were trying to combat wget barfing on *view* and *zip*. --no-directories may be enough.
      • run the scp plugin to copy from the current (random) slaves workspace to the official repository
      • delete the hudson-promotion directory when done promotion

      Unfortunately --relative should work but doesn't and IIRC it also grabs the next and previous builds.

      This plugin also doesn't work for matrix jobs as near as I can tell.

      1. I have exactly the same need. Have you managed to get the above working?

  18. Unknown User (nele_lav@yahoo.ca)

    Our company is currently testing Hudson for our SW Development and Iam currently testing this feature for our needs. One thing i can suggest for the improvement of this feature is that when doing a manual promotion, it would be great if the one who perform the promotion is required to put a note or something wherein he/she can justify why this particular build pass this level of promotion. A text area will do(to put test result or assessment coverage ).

  19. Hi,

    I am currenlty implementing a promotion status using this plugin, allong with artifactory 2.2.1 (excellent tool BTW) + power pack and the hudson artifactory plugin .

    Here after is a shell script that allows me to assign a promotion value (aka  a property value for artifactory).

    It uses Iftach Bar's script exerp, a few messages above.

     JOB_NAME=`echo $JOB_NAME | sed s/promotion/promotions/`
    OUTPUT=`grep Promoting  "$HUDSON_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER/log"`
    # The output will be something like: Promoting myJob #456
    ORIG_JOB_NAME=`echo $OUTPUT | awk '{print $2}'`
    BUILD_NUMBER=`echo $OUTPUT \| awk '{print $3}' \| cut \-b 2-`
    echo $BUILD_NUMBER
    rm -f myfile
    
    # retrieve list of all deployed artifacts that are  part of the build (could use the JSON interface yet, but need to master  it first)
    grep -a "Deploying artifact:"  "$HUDSON_HOME/jobs/$ORIG_JOB_NAME/builds/$BUILD_NUMBER/log" | cut -d:  -f3 > myfile
    while read f
    do
     rm -f properties
    #  retrieve all properties from the artifact
     curl -X GET -u  toto:toto42 "http:${f}:properties" >>properties
    
    #delete  closing </properties>
     sed -i '/<\/properties>/d'  ./properties
    
    # delete previous promotion status if already exist
      sed -i '/InternalReleasePromotion.CTA/d' ./properties
    
    
    #  insert my promotion status
    
    
     echo  "<InternalReleasePromotion.CTA>OK</InternalReleasePromotion.CTA>"  >> properties
    
    #add the closing properties
     echo  "</properties>" >> properties
    
    #upload back to  artifactory
     curl -X PUT -u toto:toto42 --data-binary @properties  "http:${f}:properties"
    done < myfile
    echo  "***********LIST**************"
    
  20. Unknown User (gongfuandrew)

    I have two projects setup: trunk and test. Trunk, upon a successful build, kicks off test. Trunk has test as its automatic build promotion criteria ( "When the following downstream projects build successfully" --> test ).

    But my trunk project never gets promoted. The kickoff works fine and both projects build successfuly, so I am not sure what is wrong.

    Thanks

  21. Unknown User (citizenkahn@gmail.com)

    What do you think of this approach? is this replicating something that's already done?

    I'm planning to add some complex promotion tasks and I was thinking having a gradle promotion helper that would allow my hudson builds to be standardized and allow for customization of promotion to be stored in source control.

    Each project would have a promotion control file which would store the following:

    • types of promotion (local, dev, qa, prod)
    • actions associated (update properties files in the artifact package, deploy artifact, start integration test jobs, update confluence pages)

    Each time I built one included artifact would be a promotion-status file that could contain

    • current promotion level
    • history of promotion changes (date/time and user – if I can figure that out)
    • source location (repos-path and revision)

    When hudson promotion was enacted the script would locate the artifact (the war file), the promotion-status file, and the promotion-control file and would handle the necessary operations.

    The promotion system would be versioned and stored in source control. The promotion tasks would be centralized in a releng-repository so I'd have centralized control with simple hudson builds but still allow customization per build.

  22. Unknown User (lostar)

    Is there a way to remove promotion mark from build?

    1. I am also interested in this feature, removing promotions.

  23. Unknown User (adam_myatt)

    I much prefer this Promoted Build plugin to the "Promoted Builds Simple" plugin. However, the "Promoted Builds Simple" plugin uses a BuildSelector in its PromotedBuildsSimplePlugin class that does this:

    @Extension public static Descriptor initBuildSelector() {
    // Add BuildSelector extension if Copy Artifact plugin is present
    try { 
        Class.forName("hudson.plugins.copyartifact.BuildSelector");
        return PromotedBuildSelector.DESCRIPTOR;
    }

    catch (ClassNotFoundException ignore) {
    return null;
    }
    }

     and defines PromotedBuildSelector which uses an action. Based on my limited knowledge this seems to make the builds promoted by the "Promoted Builds Simple" plugin available to the "Copy Artifact" plugin. Can a simple extension point be added to this Promoted Builds plugin to enable the builds promoted by it to be available to the "Copy Artifact" plugin. This would be a very valuable feature to this plugin, much like it is to the "Promoted Builds Simple" plugin. 

  24. Having a serious set-back in this plug-in we have added an automatic promotion to deploy artifacts upon a manual promotion of a a successful build - we get(see below)

    1. this used to work (like a charm I may add)
    2. If I use the built in "redploy artifacts buttom" and re run the promotion it works !!

    Any ideas?

    Return code is: 401
    	at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94)
    	at hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:119)
    	at hudson.maven.reporters.MavenAggregatedArtifactRecord.deploy(MavenAggregatedArtifactRecord.java:79)
    	at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:109)
    	at hudson.plugins.promoted_builds.Promotion$RunnerImpl.build(Promotion.java:124)
    	at hudson.plugins.promoted_builds.Promotion$RunnerImpl.doRun(Promotion.java:103)
    	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
    	at hudson.model.Run.run(Run.java:1257)
    	at hudson.plugins.promoted_builds.Promotion.run(Promotion.java:75)
    	at hudson.model.ResourceController.execute(ResourceController.java:88)
    	at hudson.model.Executor.run(Executor.java:127)
    Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: http://nexus-host.com/content/repositories/my-releases/com/myproj/adapters/adapters-asdasd/1.1_b80126/adapters-netscaler-1.1_b80126.pom. Return code is: 401
    	at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:172)
    	at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244)
    	at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
    	at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
    	... 10 more
    build hudson.plugins.promoted_builds.tasks.RedeployBatchTaskPublisher@e0898e FAILURE
    
  25. I am wanting to modify the promoted-builds plugin to incorporate security by each individual promotion item.

    I am new to plug-in development, and jelly. I can sort of follow along with it, but am hoping someone on here can provide some guidance or documentation to look at.

    in the jelly code (resources/hudson.plugins.promoted_builds/JobPrompertyImpl/config.jelly) I was wanting to add this as a tag, but not sure if I'm even going in the right direction:

    <f:entry title="Security">
        <f:descriptorList targetType="${descriptor.securityUserType}" descriptors="${descriptor.getApplicableUsers(it)}" />
    </f:entry>
    

    I'm hoping to pull the users from the project security where the users selected under Run | Update will display in the individual promotion item to be selected as users approved to manually execute the promotion.

    Any help would be greatly appreciated.

    1. Did you ever finish this?  I, too, am interested in restricting who can do promotions.

  26. Unknown User (genglish)

    I have a job which kicks off two downstream jobs. I'm using this plugin to promote the build once the downstream jobs complete and copy the resulting artifacts. I then have another promotion step which archives those artifacts however I can seem to reach those archived artifacts through the web ui (other than going to the downstream projects themselves). I can see the achived artifacts on the filesystem however.

    Is there any way to get at these through the website?

  27. Unknown User (tamerrab2003)

    I wanna use this plugin but i couldn't get some data from it.

    I can not get project svn url.

  28. Unknown User (ia@mpgamestudio.com)

    I've made a patch from v1.10 to include two environment variables from the version you are promoting. The variables are ORIG_BUILD_NUMBER (such as 33) and ORIG_BUILD_ID (such as 2010-12-01_13-08-45).

    With these numbers you can access the artifact from an old revision or the archive build directory (for instance: $WORKSPACE/../$ORIG_BUILD_ID, or something like that).

    I hope I help someone.

    Files:
    hudson_promote_build-orig.patch
    promoted-builds.hpi

    1. Unknown User (barnash)

      Wow, that's really cool.

      thanks!

    2. Unknown User (aurelien.pelletier@gmail.com)

      It does!

      Just what I needed.

      I thought BUILD_NUMBER and BUILD_ID environment variables were supposed to give the same information as your ORIG_ variable, but they don't.

      Should be included in the official plugin.

      1. Unknown User (ia@mpgamestudio.com)

        I'm glad it helped.

        As the promotion process is in fact a new build, the environment variables BUILD_NUMBER and BUILD_ID correspond to this new build instead of the build that you are promoting.

        1. Thanks a lot,

          This is really useful, was it included in the official release yet? I don't see any ORIG_ tags in my environment variables on the promotion.

  29. Unknown User (indrg)

    Can I promote a build using remote API? We have a sanity test outside Hudson that can execute remote API to promote the Hudson build which passes the test.

    Thank you.
    -Indra

    1. Yes, you can hit the url behind the Force Promotion feature.  Just take a look at the source code on the page where you see the button and add that to you external script.

      1. Unknown User (aurelien.pelletier@gmail.com)

        Here is a bash script that does just this. Does not work if there a space in the promotionJobName.

        USER=
        PASSWORD=
        ROOTURL="http://jenkins/"
        BUILDNUMBER="48"
        JOB="jobname"
        TARGET="promotionJobName"
        URL="$ROOTURL$JOB$BUILDNUMBER/promotion/forcePromotion?name=$TARGET"
        
        COMMAND="/usr/bin/wget --auth-no-challenge --http-user=$USER --http-password=$PASSWORD $URL"
        echo $COMMAND
        $COMMAND
        
  30. C W

    What is "Pending promotion (promotion not queued. Please re-execute promotion)" ?

    I have set up a job, with Manually Approved promotion, that sends an Editable Email Notification and builds another project upon Promotion. I then did a few builds. When I go to the /server:8080/job/my-job/42/promotion/? page and click the Approve button, I see the message "Pending promotion (promotion queued)". When I refresh the page, then I see "Pending promotion (promotion not queued. Please re-execute promotion)". The email never gets sent and the other job does not get kicked off. I don't see any errors in the system log. Any ideas ?

    1. I've got a similar problem.  I've downgraded to 1.11 for the time being, but the logs for the promotion are typically in the main hudson directory under jobs%JobName%\promotions%promotionName%\builds%BuildTimestamp%\

      For this error the only thing I'm seeing in the logs is:

      Legacy code started this job.  No cause information is available
      FATAL: null
      java.lang.NullPointerException
          at hudson.plugins.promoted_builds.Promotion.getUrl(Promotion.java:61)
          at hudson.model.Run.getEnvironment(Run.java:1771)
          at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:725)
          at hudson.plugins.promoted_builds.Promotion.getEnvironment(Promotion.java:74)
          at hudson.plugins.promoted_builds.Promotion$RunnerImpl.decideWorkspace(Promotion.java:107)
          at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:409)
          at hudson.model.Run.run(Run.java:1362)
          at hudson.plugins.promoted_builds.Promotion.run(Promotion.java:93)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:145)
      

      Though there is a long line of characters before the null pointer exception.  As far as I can see, it looks like one of the targets where it creates the URL is failing, but I'm really not sure.  I'm trying to play around with it a bit more before putting in the ticket, but if anyone has more info, please feel free to share.

      1. C W

        Yes, I'm getting the exact same error message.

        1. Wiki comments aren't really monitored very well, so for problems please file a ticket.

          A separate conversation in IRC led me to this thread. I've filed JENKINS-11609 for this and solved it.

  31. I tried to upgrade to 2.0 and I have jobs that have multiple promotions (ex. DEV, QA, UAT, PROD).  Once a user clicks on the "Force Promotion" button for one of the promotion jobs it runs all of the jobs instead of just the one i clicked on to promote, like it is suppose to do.  I have downgraded to 1.11 for the time being.

    1. I think this is an incidental effect of changing how manual approval is done.  Previously, if you didn't specify any conditions at all on your promotions, you could just force each promotion individually.  Now, having no conditions on your promotion is somewhat ambiguous as it doesn't immediately fire the promotion but it can fire at a later date if Jenkins checks to see if any pending promotions have there conditions met.  In this case it thinks that it does.

      To workaround this for 2.0, check the Manual Approval checkbox and you will then have a separate button called approve to click on the UI.  This should be preferred instead of Force Promotion as that doesn't take into account any pending conditions and just forces the promotion (as expected).

  32. Is there a way to prevent manual promotion if the build was not successful. I am running Jenkins 1.411 and Promoted Builds plugin 2.1 and am able to manually promote even if the build failed.

  33. Hi, 

    I don't know quite how to solve this: 

    I have quite many build projects in jenkins (several projects with several branches each), I would like to enable them for promotion (using the promotion plugin).

    The promotion process would be pretty much the same for all the different jobs. So I wouldn't like to write all the promotion steps in each of the build projects, but rather have a single promotion job, able to promote them.

    The way I see it a user would manually select and promote one build from either build project. The build would trigger a new build of the promotion job, which retrieves the information from the promoted build and does the promotion.

    My problem is that I don't seem to see a way to retrieve the artifacts from the promoted build.

    If I use the copy artifact plugin it forces me to choose an upstream job, and I seem not to be able to write more than one. The help says that I can use the $ variables, but I don't see how, as I don't see the promoted build id among the environment variables.

    I'm pretty sure this could be solved, but I don't see how.

    Anyone has an idea?

    thanks.

    1. Unknown User (aurelien.pelletier@gmail.com)

      I'm not sure I understand your question but here is how I use the copy artifact plugin to copy the artifact of the promoted plugin

      • Project name = same as the current project (but could be a parameter in a build with parameter
      • Which build = specific build
      • Build number = $PROMOTED_NUMBER
      1. Thanks that number is useful, but how can I pass it to a different job? so that it can promote the code? 

        Actually I'm realizing that what I want to do may be impracticable, for example the other, shared job wouldn't even be capable of tagging the sourcecode according to the promotion. 

  34. I need to have a nightly task for promoting automatically the lastStableBuild of several jobs.

    I couldn't find how to get this done, I've tried using upstream and downstream promotions with no success. I've tried also using a wget on the shell, but simulating the browser approval call is not so easy.

    Has anyone any idea on how this could be achieved? 

    thanks,

    Giulio

  35. I'm sure I must be missing something but how can we remove the promotion?

  36. Come on this has been asked multiple times:

    HOW DO WE REMOVE THE PROMOTION????

    Is that so difficult to tell :

    IT CAN'T BE DONE

    or

    HOW IT CAN BE DONE.

    1. Ditto - remove/revoke promotions - how?

      Even if it's a manual thing, like deleting symlinks under the promotions dir. That would help.

      What are the repercussions of manual promotion symlink deletion. Does it need to be cleaned up elsewhere?

  37. Is there a way to programmatically retrieve and update the promotion name, criteria, and actions?  Normal Jenkins job configurations can be retrieved/updated by getting the config.xml.  But the config.xml of a job with promotions simply has a section that lists the names of the promotion processes and nothing else.  Since each promotion is really a sort of job, can the config.xml of the promotion be retreived/updated?

  38. I'm trying to get my Jenkins pipeline to 'split' jobs and then 'join' them later in order to run long-running tasks in parallel. I've first tried the Join plugin and now the Promoted Builds plugin, but they both seem to suffer from the same limitation. Consider the below picture:

    I need my Promote job to kick off after both 'branches' of the split complete. It works fine if each branch is only one job 'deep', but as you can see in the above picture, one of my branches is TWO jobs deep.

    Does anyone have any advice for my situation? Is there another plugin that might do what I need, or am I simply using this plugin incorrectly? I've tried using the 'Copy Artifact' plugin to pass a fingerprinted artifact all the way down the pipeline, but I sitll can't get the promote job to reliably run.

    1. Fingerprints are CRITICAL in this scenario.  The "build" project must be the first project to introduce the fingerprinted file into Jenkins - it cannot use an existing one.  You can verify this by going to a specific build of "build" and clicking See Fingerprints.  The fingerprinted file that you'll pass down to the other projects must originate in "this build".  Then the "code coverage" and "test" jobs must also fingerprint that same file.

      1. I see. Maybe I don't understand how fingerprints as well as I thought I did. When I look at build #43, it shows a file that was created with build #43 (indeed, the filename is 'artifact43.txt', but it claims that the original fingerprinter was build #7!

        1. That would be the source of the problem.  For this to work, your "build" project has to be the origin of the fingerprint.  How you start your down-stream jobs (in the publishers or as build steps) and when you finger-print (via a Conditional Build step or via the publisher) will also have an impact.  In general, you need to have the file fingerprinted BEFORE you start the downstream jobs.

  39. Hi, We make extensive use of the Jenkins REST API but I am unable to find any properties from the promoted build plugin using the build api job/buildnum/api/xml. Is it possible to check a builds promoted status through the Jenkins REST API ?  The promoted build plugin is an excelent fit for our QA testing workflow but we need some form of remote access to really leverage the full power of this plugin.

    Many thanks

    Richard

    1. I don't believe the promotion status is currently exposed. Vote for issue JENKINS-9259 (if you have not already)

  40. Is there a way to kick off a job to run with a specific build? To illustrate what I mean, I am using this plugin to launch a deployment job. I have this deployment job set up to copy artifacts from the project where the promotion is approved, using a permalink to the "Latest promotion: XXX" where XXX is that promotion. I had thought that simply re-executing that promotion on an earlier build would work, however it simply picks up the latest build where that promotion has been made.

    Right now, I am simply using another job with a parameter that allows a specific build to be entered. However, a "one-button rollback" would be nicer and it seems like Re-execute promotion on an earlier build could be that button.

    Can anyone think of something I'm missing? Or another way to do this? If not, it would seem valuable to add to the available permalinks something like "Latest promotion execution: XXX".

    1. OK, I was able to get this going through the use of the Parameterized Trigger Plugin. The configuration wasn't fun, but it does work.

      • In the main job:
        • In the promotion, instead of action "Build other projects", use action "Trigger parameterized build on other projects" and indicate the same deployment project
        • Set to always trigger
        • Choose predefined parameters and enter:
          PROMOTED_NUMBER=$PROMOTED_NUMBER
      • Now in the deployment job:
        • Indicate that this build is parameterized
        • Add a "Build selector for Copy Artifact" parameter
        • Name it BUILD_SELECTOR
        • Default selector Specific Build
        • In the build, enter $PROMOTED_NUMBER
        • Now down in the Copy Artifact build step, indicate "Specified by a build parameter" for "Which build"
        • Parameter name BUILD_SELECTOR

      And that does it. Now each promotion will deploy the exact build from which it was executed. This means that you can roll back to any deployment for which there still exists build artifacts.

      1. Thanks Chris. It was really helpful.

        But i find one issue with approach. On manual approve for promotion, if i promote and other deploy job fails. How will it notify back to promotion to fail. I mean to say on promotion approval, it  triggered deploy job and becomes star. But if deploy job fails, the start should become red circle (promotion failure).

        Thanks

        Pawan

        1. You have a point.  I just haven't found another way to do what I needed to do.  Perhaps there is a downstream link that can be made that will mark the job "unstable"?  However, I'm still just a Jenkins newbie and learning how to do the basics.

          1. No problem. Thanks again for this idea.

      2. This was a great help, thanks for the info!

    2. I set it up like this and it works for me (maybe my need is not as complex as yours, or they changed things):

      Project name: foofoo

      • -- Promotion process --
        • ...
        • Actions
          • [#] Copy artifacts from another project
            • Project name: foofoo
            • Which build: Specific build
              • Build number: $PROMOTED_NUMBER

      For example, my latest build is 10.  I decide to re-promote build 9, so I go back to build 9, pull up the promotions, re-execute the one I want (dev, qa, or prod, in my case), and the artifacts from build 9 get deployed.

      Thus, if I tell the prod promotion to keep the build forever, I imagine I could rollback to any prod version at any time.  I'm still testing Jenkins for the first time though.  It seems this plugin could be a simplified alternative to the pipeline plugin allowing me to keep the entire SDLC in one project.

    3. After I finished testing with only promotions (as outlined in my last reply) I started testing with pipelines for more complex builds.  I noticed your procedure could be shortened as follows:

      • In the main job:
        • In the promotion, instead of action "Build other projects", use action "Trigger parameterized build on other projects" and indicate the same deployment project
        • Set to always trigger
        • Choose predefined parameters and enter:
          PROMOTED_BUILD=$PROMOTED_NUMBER
      • Now in the deployment job:
        • Indicate that this build is parameterized
        • Add a "Build selector for Copy Artifact" parameter
        • Name it BUILD_SELECTOR
        • Default selector Specific Build
        • In the build, enter $PROMOTED_NUMBER
        • Now down in the Copy Artifact build step, set "Which build" to "Specified by a build parameter" "Specific Build"
        • Parameter name BUILD_SELECTOR Build number: $PROMOTED_BUILD
  41. Can I "promote" historical builds in any existing Job in the system? I tested it today, and found out I can only mark builds created from the moment I added the configuration.

    Is there's a way around this limitation?

  42. I cannot see the ChangeLog for the 2.5 version. Keep in mind this issue: https://issues.jenkins-ci.org/browse/JENKINS-13472

    Regards

  43. I have a promotion named "Promote To Production".  This production promotion can only be executed only if another promotion "Promote To QA"  is approved and promoted. But if I accidentally click "Promote To Production" prior to "Promote To QA",  the "Promote To Production" will not execute with a message saying "Unmet Qualification: Upstream promotions:  Promote To QA".  But this "Promote To Production" execution request is actually still in the invisible queue list.  And consequently, if I click to execute "Promote To QA",  the last request above-mentioned of "Promote To Production" execution will execute immediately.   You know,  I just click on the "Promote To Production" wrongly,  I think many people else would probably make this mistake as well,  so I was suggesting if it's wrongly clicked,  people should have a place to cancel the request to avoid it to still be executed later.

    Currently in the promotion status page only shows the historical promotions, if the suspended promotions can also be listed out in this page, then maybe we could cancel the suspended promotions here.

    1. +1 - agreed, having the ability to both cancel pending promotions and back out accidental ones is the one thing this plugin is missing before it can truly be considered part of a complete deployment management solution.

  44. I am getting NPE this issue: https://issues.jenkins-ci.org/browse/JENKINS-10395 when combining this to trigger a Parameterized build.

    Jenkins: 1.455

    Promoted Build Plugin : 2.5

    Parameterized Trigger Plugin: 2.15

    Thanks.

    -Indra

  45. Unknown User (kumarganesh20)

    I am trying to trigger Hudson build using Jenkins as follows:

    from jenkinsapi.jenkins import *
    from jenkinsapi.job import *

    jenkin = Jenkins(“http://hudsonserver”, “username”,”password”)
    myJob=Job(“http://hudsonserver/job/sample_trigger_build/”, “sample_trigger_build”,jenkin)
    parameter=”sample_file.txt”:”/home/user/sample_file.txt”
    myJob.invoke(“token”, False,False,3,15,parameter)

    I was able to trigger the build with string parameter, but for file parameter I am getting urllib2.HTTPError: HTTP Error 500: Internal Server Error.. Please help me in this.

  46. I'm using the LTS release and updated to 1.466 yesterday. After that I can't promote any maven projects, because I get a IllegalArgumentException (sorry, no Stacktrace at hand).

    Could it be that this plugin isn't yet ready for the LTS version?

  47. In the oldest release I took, "SVN Tagging is now a permitted promotion step" to mean that creating an svn tag was available as an action.  Is that incorrect?  If not are there prerequisites I may be missing?

  48. Is there a way to change the Recent Promotions timeout? It appears that builds only show up for a few minutes in recent promotions.

  49. Is there a way to change the Recent Promotions timeout? It appears that builds only show up for a few minutes in recent promotions.

  50. Hi, I am a happy user of the promoted builds plugin. Unfortunately I am managing a huge number of jobs via the REST / JSON API. Is there a way to update the Promoted Builds sub-config of a job via this remote API? E.g. /job/<JobName>/promotion/config.xml

    Thank you for your work on this plugin!

  51. hi, now I am use promotions in my jenkins job. We have a request to create jenkins job automatically. We are use python module jenkinsapi to create them.

    But some jobs have promotions , I can't find good solution to create promotions. One idea is to copy promotions files  from other job ,then modify these files. But jenkins needs to be restarted.

    Is there a better way to do this?  I will be thankful if someone can give some help.

  52. hi, now I am using promotions in my Jenkins job. We have a request to create Jenkins job automatically. We are use python module jenkinsapi to create them.

    But some jobs have promotions , I can't find good solution to create promotions. One idea is to copy promotions files  from other job ,then modify these files. But jenkins needs to be restarted.

    Is there a better way to do this?  I will be thankful if someone can give some help.

  53. I think there is very much a need to copy artifacts from permalink SELECT / OLD / LATEST. It would make so much more sense and flexible to do a select promotion rather than only doing a permalink - LATEST option. 

    Is this feature already available? Currently you need to go with workarounds to achieve this functionality, which is pretty ugly. Can this extended feature be added please?

  54. Thanks for such a nice plugin (smile)

    I will be thankful to you if you provide following Features to Plugin(lightbulb)

    This plugin is not compatible with Windows Exe Runner plugin. In Build Action Windows Exe plugin is not prompting. Can you please suggest what to do to enable Windows exe runner plugin in Build Action.

    • Visible in build Task

    • But not visible in Promotion Task Action

    Can you please suggest the changes.

    Thanks for very useful plugin (thumbs up)

    1. Solved... Fix was in Windows Exe Runner(version 1.2).

  55. Hi,

    We are getting issue in retrieving Global Password Field.

    Steps to reproduce

    Step 1 : 

    Add a Global Environment Variable : 
    Step 2 : 

    Add a promotion Step in Job and trying to access Global build password field :Step 3 : In Output we are not getting value it is empty string. 

    Step 3 : In Output we are not getting value, it is empty string

    Please provide the solution for the same.

    Thanks

    Arpit Nagar

  56. Will we ever see version 2.15?

    2.14 has been broken for months and there are many fixed bugs pending a release.

    What does it take to get a new build out?

  57. Hi

    I am looking at automating several promotion tasks with an 'uber' task that triggers the specific promotions via a Groovy script.

    I have written a script that gives me the lastest build for each job, but I don't seem to able to work out how to actually trigger a manual promotion task

    Is there an example or a hint anyone can give me

    Thanks

    1. @Mark,

      I am also interested in that info and can't seem to find it at the moment. Have you come across the answer to your question by any chance ?

  58. Here is the workflow I currently have in place:

    Build job runs with github commit changes.

    i have manual promotions to deploy the build. The promotions are:

    Deploy to Int

    Deploy to QA

    Deploy to Production

    with the Deploy to Int promotion, not only does it deploy, but also sets 'keep build forever'.

    here is what I would like to have:

     if a build turns out to have a bug in it that is found in Int or QA, I would like to 'demote' the build.  In a perfect world, it would remove the promoted status, and disable keep build forever.

    however, if official demotion isn't a possibility, I would like a promotion action of 'disable keep build forever', so that I can manually emulate a 'disqualify build'.  It may not remove the promotion status, but at least the build would drop off with regular cleanup.

    Of course, I could manually click 'Don't keep this build forever', and then wait for the cleanup.

    i could even delete the build.  I just think that if there is a promotion process, there should be a demotion process, which would seem more intuitive.

    Thanks for hearing my suggestion!

  59. Here is the workflow I currently have in place:

    Build job runs with github commit changes.

    i have manual promotions to deploy the build. The promotions are:

    Deploy to Int

    Deploy to QA

    Deploy to Production

    with the Deploy to Int promotion, not only does it deploy, but also sets 'keep build forever'.

    here is what I would like to have:

     if a build turns out to have a bug in it that is found in Int or QA, I would like to 'demote' the build.  In a perfect world, it would remove the promoted status, and disable keep build forever.

    however, if official demotion isn't a possibility, I would like a promotion action of 'disable keep build forever', so that I can manually emulate a 'disqualify build'.  It may not remove the promotion status, but at least the build would drop off with regular cleanup.

    Of course, I could manually click 'Don't keep this build forever', and then wait for the cleanup.

    i could even delete the build.  I just think that if there is a promotion process, there should be a demotion process, which would seem more intuitive.

    Thanks for hearing my suggestion!

  60. Is there a way to supply more custom icons for marking the promotions?

  61. I guess I wasn't clear in my question. I am not asking how to configure more promotions. I am asking how to add more icons for the promotions dropdown list.

    Currently, there is Gold, Blue, Green, Orange, Purple, Red. Only 6. I have jobs with upto 20 different promotions, and would like to uniquely identify them by the icon (preferably self uploaded)

  62. I am in the progress of upgrading to Jenkins 1.557 and Promoted Builds Plugin 2.17.  I have setup the Promote builds to be able promote to DEV and QA.  Each of these promotes has the "Only when manually approved" criteria checked with an approvers=my user name.  When I go to the "Promotion Status" screen for a particular build a see the "Force promotion" and "Approve" button.  The Approve button seems like it is working correctly and it only allows users that I have added the the Approvers list to submit the promotion.  The Force promotion button allows any user that is logged in to click on it and complete a promotion.  Once the Force promotion button is click and it runs it will no longer allow you to click on the force promotion or approve. 

    As you can see in my 3rd screen shot below, I clicked on "Force promotion" button for DEV and I clicked on the "Approve" button for QA. 

    Is there a way to remove the "Force promotion" button from the screen?  It does not seems the security is working for the "Force promotion" button and it is allowing all users to click on it, which is very bad if we don't want all users promotion to QA, UAT, or PROD.

    I think the behavior of the "Approve" button is what we are looking for.

    1. The "Force Promotion" button only shows up to full admins and people with "Promote" permission. Your general users should not have "Promote" permission, and therefore will not see it.

      And it can be re-executed by clicking "Re-execute Promotion" button. It is equivalent to "Force Promotion"

      1. You are correct, after changing the security for my users they are no longer able to see the "Force promotion" button.  For the admin's that can see the button and accidentally click on it instead of approve, it does not show the "Re-execute Promotion" after the force promotion is complete if they click on it instead of the "Approve" button.

  63. Hi,

    with manual approval option I am getting approve button to promote build for next level,but is there any way/plugin to get hold/reject button also?

    please respond.

  64. I have a couple of questions. We use this and use Active Directory groups to determine who has access to approve and re-execute builds.

    The Approve button works perfectly...if a user is in the AD usergroup with access, they see the button and if they don't they will not see the button. However, when we go to Re-excetute promotion, the button will show up regardless of access. If the user doesn't have access they will be redirected to a blank screen.

    Ideally, the Re-execute should have the same functionality, shouldn't it? When I went through the code I found that it is looking only for specific users that have access and skips over looking to see if the user is a part of a usergroup that has access.

    Is there a fix for this?

    Thanks.

    1. I have exactly the same problem Matthew and I was just about to log an issue for this.  Our case is the same as yours - users who are in the "Developers" AD group can manually approve promotions but they are getting the "white screen" when doing a re-execute.  From your looking at the code, it looks like it's not processing group membership the same then for the inital approval Vs the re-execution.

      IMHO, the re-execution should use the same logic and permissions as the inital approval.

      1. That is my opinion as well. I have updated the code (it only required about 7 lines of modification), and am in the process of trying to find out how to submit the changes to help everyone included. Basically, the issue was that it was looking for the logged in user to be the same as what was allowed. I modified our plugin with the same functionality that was used for the initial approval.

        I am in the process of trying to find out how to submit the changes so everyone can benefit.

  65. Ever since 2.15 this has been broken WRT the expansion of injected variables. See JENKINS-22679

    The fact that this plugin stores it's config in separate files from the main job config also means that any tool/plugin designed to work with jenkins config.xml files, like the DSL plugin, git snapshot plugin, etc, will not work with this plugin. It always requires special case handling.

    The job promotion concept is a great feature to have in a CI framework. It's too bad that this plugin is so broken. Another problem is has is that promotions cannot be undone. This has been a pending request since 2012.

    Would not recommend this for new work. It appears to do the job initially, but then becomes a maintenance headache every step of the way due it's configuation anomalies and the sheer number of old bugs it carries forward. There are 98 bugs from the past 6 years that have never even been assigned. One blocker from over a year ago and 96 major.

  66. Any way for distinguishing which jobs for a given project has any promotions via the Jenkins API itself (ie, http://jenkins/PromotedJobA/api/python)? I was trying to access that information so I could grab all the "pending" changes between last promotion and current build since that does not appear to be present in current functionality. Currently, we are using the promoted jobs plugin to manually approve when changes are moved to our production servers so it'd be incredibly helpful to know which changes are waiting to be approved and/or have not yet been moved to production. We have an approach in place which works, but it's incredibly hacky.

  67. Is there anyway to change the "Approve" button to "Submit", we have planned to use this plugin as a workflow system.  Our system demands an option for the user to approve or reject the workflow. 

    Please help

  68. I think you should list PROMOTED_DISPLAY_NAME in your description above.  I had to look at the source code to find it.  This, when used with the Version Number Plugin allows you to dynamically build a version number, set it to the build label, and then retrieve it from a promoted build, something that is VERY handy in a "Promote To QA" type step.

  69. Are the promotion condition like "Promote immediately once the build is complete based on build parameters" and "When the following downstream projects build successfully" AND or OR connected?

    In my case it does not work having enabled both condition.

    The promotion status page says "All conditions met" but no promoted run...

  70. Maybe you can help me with this problem:

    for our project, there is no way to automatically promote a build. so i want some users to do the qa and promote a build manually. this can happen some days after the build was generated.

    after promoting i want to zip all binaries of thet build and publish them on a ftp server.

    the biggest problem i see is that at the time of promoting several new builds might have been generated and the artifacts are not in that version which belong to the promoted build.

    can you pls give me some hints how i could manage my process?

    1. PROMOTED_JOB_NAME and PROMOTED_NUMBER. These two (among others) are automatically passed to the promotion process, at the time of execution. By using the combination of the two, you can use "Copy Artifacts" plugin to specify which job and which run of the job to use to retrieve the artifacts inside the promotion process (never ever use artifacts from workspace, always copy artifacts with the above plugin).

      Here is a detailed explanation: http://stackoverflow.com/questions/15126059/how-to-promote-a-specific-build-number-from-another-job-in-jenkins/15206921#15206921

      There, it's using a second job for the processing, but nothing prevents you from doing the same within the promotion process itself

      1. thanky for your quick reply. but i have no access to artifacts of a previous build. they are not stored on the build server, they are deleted after every succesfull build.

        so my idea was to re-run a specific build with exactly the same source, pulled from svn repo, after that deploy it on the designated server(s)

  71. My Promoted builds plugin version is 2.21. Could who know if it can clone or duplicate a new promotion process?

  72. My Promoted builds plugin version is 2.21. Could who know if it can clone or duplicate a new promotion process?

    1. No, it cannot. There is no such feature right now

  73. I have a promotion that runs a simple plugin to increment some meta data counters that are stored in the job.  This used to be very fast.  But now, with no changes to my promotion or the simple plugin, my SCM plugin is being invoked.  This promotion step used to take 1-2 seconds and now takes 30-45 seconds because my SCM plugin is horribly slow and inefficient.

    I suspect this behavioral change was introduced with JENKINS-13751.

    1. Yes, it was a wrong fix. It has been reverted in 2.24.1

  74. I have a promotion that depends on other promotion get completed. For example Prod is depended on pre-prod. Today I had a situation that a user accidentally promoted to prod but it was stopped because pre-prod was not deployed. The user than selected the pre-prod deployment. This caused the pre-prod to be deployed and then subsequent prod. However because the production promotion was queued the deployment was done by "SYSTEM" and not the User. I feel like this is a bug because it would indicate the system is responsible for the promotion. My question is do you know if the queuing is being logged to a file or the db? Is there anything that would indicate that build was queued because of this evaluation fail?

  75. Hi, is there any way when I approve an promotion, have a text box or something to track the change order that promotion was requested?

    Thanks

  76. I have a promotion step that is behaving badly, after being good for quite some time.

    Jenkins version is 1585; promoted builds plugin is 2.19.

    It's executed manually, and when the Approve button is pushed, it *seems* to have submitted the promotion job -- however, it doesn't; no promotion job is actually run.  The Approve button turns to Re-execute promotion.

    If you try to re-execute it, you get a 404 page.

    If you use the dreaded Force Promotion, then it runs normally.  However, you lose the ability to re-execute, if that's necessary (rarely is, but occasionally).

    All other promotions -- including others in this specific job -- are running correctly.

    I've poked around a bit in the configuration directories on the master; from what I can tell, it looks OK.

    Any ideas?  My most likely alternative at this point is to create a new promotion step that performs the same actions, and switch to that.  But would like to know what caused this, so we can avoid it in the future.

  77. I am using Jenkins version 1.635 with promotion plugin 2.27.  Whenever I use the jira plugin in the promotion block (to create new version, or set a jira release version) the promotion fails and the jira action fails.  Outside of the promotion block the jira action is successful (ie. as a post build step).

    The jira plugin version I am using is 2.0.3.

    Has anyone else run into this issue?

    1. Please create an issue in Jenkins JIRA and add the promotion log there.

      1. Thanks for the reply Oleg!  

        I opened JENKINS-36862 and it's assigned to you :)

  78. I am using Jenkins version 1.635 with promotion plugin 2.27.  I am wondering if there's a way to get the formatted version number from the promoted job and use it in a groovy script in the promotion process?  The formatted version was created using "create a formatted version number"plugin in the main job configuration.

    Also, is there a way to pass the parameter name/values of a user defined configuration matrix (from a multi configuration job) to the promotion process?

  79. I can't seem to find any documentation on how to use the KeepBuildForeverAction from a DSL plugin groovy script? I simply want to mark the build to be kept forever as a promotion action, but I don't know what should be put to the groovy script.

  80. After upgrading from version 2.27 to 2.28 we identified issues with our promotions that had the criteria of "Promote immediately once the build is complete" were failing because the promotion was creating a new workspace with "@2" appended at the end.  Downgrading back to 2.27 resolved the issue.

    Jenkins 2.19.4

  81. Is there any plan on incorporating the fix from Brian Gibbons:

    I tried making the change that Dominik suggested (https://github.com/FarmGeek4Life/promoted-builds-plugin/commit/230d61070b3883234f43db7eb0090ddaa782fb62) and have so far not seen any problems. It has fixed the issue with using managed scripts in build promotion processes in my Jenkins instance, but my instance also isn't very complex (there are no folder-level managed scripts, for example, but a job inside a folder was able to access the global managed scripts). 

    This fix was mentioned in JENKINS-40803.

     

  82. Hi,

    I am using jenkins version 2.107.3 and promoted builds plugin version 3.1. I am facing issue with promotion plugin, all the users who have login to jenkins are able to approve the build for promotion not only who are mentioned in approval list. 

    I am stuck with the issue, can someone please help to troubleshoot the issue, according to requirement only users who are mentioned in approval list should be able to approve the build.

     

    Thanks

    1. Do your users have global Administer permissions? If no, please create a JIRA ticket and provide your security configuration there

  83. Oleg Nenashev, Thanks for your response.

    Yes, they do have administrator permissions. Is it possible that administrators should not be able to approve, only users listed in approval list should be able to approve?

    We have one other jenkins server with version 2.46.3 and promotion plugin version 2.30, but that does not allow all admin users to approve and execute promotion, only users mentioned in approval list can approve.

    1. "Yes, they do have administrator permissions. Is it possible that administrators should not be able to approve, only users listed in approval list should be able to approve?". No, it is not possible in newer versions. If a user have administrative access to Jenkins, there is no way from preventing him from doing promotions. Just because he will be able to tweak system configuration and gain any permissions if needed.

      It would be possible to add an option which hides a promote button for Admins, but generally there is no way to prevent promotions by admins on the recent versions and on 2.46.3 / 2.30. My recommendation would be to rather reconsider the security model, because All-admin instances are generally not secure

      CC Devin Nusbaum

       

      1. Shobhit Gupta I agree with Oleg here. While we could add an option to change how permissions work for admins, it seems like you would be better off by removing Overall/Administer permission from some of your users and instead giving them more specific permissions such as Promotion/Promote as needed.

        1. Thank you both Oleg NenashevDevin Nusbaum, your quick response is really appreciated and helpful to me.

          Devin Nusbaum, I like your idea of removing Overall/Administer permission from some of your users and instead giving them more specific permissions such as Promotion/Promote as needed. I will work on your idea to accomplish my task.

  84. Is there any way to promote from a Rest API? I tried everything available online on StackOverflow and wiki but nothing is working.

Write a comment…