How to promote a specific build number from another job in Jenkins?

Question

I installed the Promoted Build Plugin from Jenkins and now I'm facing some troubles to promote a build from an existing job. Here is the scenario:

1. There is an existing Nightly Build job that runs every night running all the tests and metrics needed;

2. There is an existing Deploy Build that accepts a parameter ${BUILD_NUMBER} and deploys the build that has the corresponding ${BUILD_NUMBER} from the Nightly Build

   • Say the [Nightly Build] ran and successfully built the artifact #39
   • Now I can just run the [Deploy Build] passing in #39 as a parameter
     • The artifacts from [Nightly Build] #39 are going to be deployed

So far so good. Now is the part where I want to add the Build Promotions...

Is there a way to promote the Nightly Build #39 (notice that it was already built before) from the Deploy Build? Or maybe even from somewhere else, quite frankly I`m kind of lost here :(

I don`t see them with a clear Upstream/Downstream relationship, because they don't have a: always runs this build and then the other during the execution - the [Deploy Build] is executed sometimes only and not always after the [Nightly Build].

Mawkish

Answer 1

Update as of version 2.23 of Parameterized Trigger Plugin:

With version 2.23+ behavior changed (thanks AbhijeetKamble for pointing out). Any parameter that is being passed by Predefined Parameters section of calling (build) job has to exist in the called (deploy) job. Furthermore, the restrictions of called job's parameters apply, so if the called job's parameter is a choice, it has to have all possible values (from promotions) pre-populated. Or just use Text parameter type.

Solution

Yes, I have the exact same setup: a build job (based on SVN commits) and manually executed deploy job. When the user selects any build from the build job (including older builds), they can then go to Promotion Status link and execute various deploy promotions, for example Deploy to DEV, Deploy to QA, etc

Here is how to setup the promotion on build job:

• You will need these plugins: Parameterized Trigger Plugin, Promoted Builds Plugin
• You will also need to setup default Archive the Artifacts post-build action on this build job.
• Check mark Promote builds when
• Define Name "Deploy to DEV"
• Under Criteria check mark Only when manually approved
• Under Actions use Trigger/call builds on other projects
• In Projects to build enter the name to your deploy job here
• Check mark Block until the triggered projects finish their builds
• Mark this build as failure if the triggered build is worse or equal to: FAILURE (adjust according to statuses of your deploy job)
• Predefined parameters (Code A)

Code A:

Server=IP_of_my_dev_server`  
Job=$PROMOTED_JOB_NAME`  
BuildSelection=<SpecificBuildSelector><buildNumber>$PROMOTED_NUMBER</buildNumber></SpecificBuildSelector>

Above, in the Predefined parameters section, the name to the left of = are the parameters that are defined in your deploy job. And to the right of = are the values that will be assigned to those parameters when this promotion executes. Defines three parameters Server, Job and BuildSelection.

The parameter Server= is my own, as my deploy job can deploy to multiple servers. However if your deploy job is hardcoded to always deploy to a specific location, you won't need that.

The Job= parameter is required, but the name of the param depends on what you've setup in your deploy job (I will explain configuration there). The value $PROMOTED_JOB_NAME has to remain as is. This is an environment variable that the promotion process is aware of and refers back to the name of your build job (the one where promotion process is configured)

The BuildSelection= parameter is required. This whole line has to remain as is. The value passed is $PROMOTED_NUMBER, which once again the promotion is aware of. In your example, it would be #39.

The Block until the triggered projects finish their builds check mark will make the promotion process wait until the deploy job finished. If not, the promotion process will trigger the deployment job and quit with success. Waiting for the deploy job to finish has the benefit that if the deploy job fails, the promotion star will be marked with failure too.

(One little note here: the promotion star will appear successful while the deploy job is running. If there is a deploy failure, it will only change to failure after the deploy job finished. Logical... but can be a bit confusing if you look at the promotion star before the deployment completed)

Here is how to setup deploy job

• You will need Copy Artifacts plugin
• Under This build is parameterized
• Configure a parameter of type Choice (or Text) with name Server (this name has to match with configuration in promotion's Predefined Parameters in previous section)
• Choices: Enter list of possible server IPs that would be used by the promotion's Predefined Parameters in previous section (see update note below)
• Configure a parameter of type Choice (or Text) with name Job (this name has to match with configuration in promotion's Predefined Parameters in previous section)
• Choices: Enter the name of your build job as default. This is only needed if you trigger the deploy job manually. When the deploy job is triggered from promotion, the promotion will supply the value (the Job= from Predefined parameters that we configured). Also, if there is no value passed from promotion's Predefined parameters, the first choice value will be used. If you have a 1-to-1 relationship between the build and deploy jobs, you can omit the Job= parameter in promotion's configuration.
• Update: since version 2.23 of Parameterized Trigger, the available choices in the deploy job configuration have to have all possible values coming from the promotion's predefined parameters. If you don't want that limit, use "Text" instead of "Choice"
• Configure a parameter of type Build selector for Copy Artifact with name: BuildSelection
• Default Selector: Latest successful build
• Under Build steps
• Configure Copy artifacts from another project
• In Project name enter ${Job}
• At Which build choose Specified by a build parameter
• In Parameter Name enter BuildSelection (without ${...}!)
• Configure the rest accordingly for your artifacts that will be copied from build job to deploy job's workspace
• Use the copied artifacts inside the deploy job as you need in order to deploy

So now, with the above deploy job, you can run it manually and select which build number from build job you want to deploy (last build, last successful, by build number, etc). You probably already have it configured very similarly. The promotion on the build job will basically execute the same thing, and supply the build number, based on what promotion was executed.

Let me know if you got any issues with the instructions.

Kelci

+1 Great description, better than the documentation. Edited your answer (added formatting and renamed build parameter "Build Selector" to a name without space) – Liles

Trying to implement something like this ... When you say "Check Promote Builds When" ... where are you doing this ? I am unable to find this ... – Caprine

@JamesGawron On the job configuration page, right after "This build is parameterized" checkbox (which is there be default), you will see "Promote builds when..." checkbox (only if you installed the plugin) – Kelci

Ah got it. I set up a build and deploy job now, and I'm trying a test promotion of the build job. The promotion is kicking off the deploy job, but that job is now failing because it cannot find the build artifact to copy. Unable to find project for artifact copy: This may be due to incorrect project name or permission settings; see help for project name in job configuration. Build step 'Copy artifacts from another project' marked build as failure ................ curious, as the project name appears to be correct. – Caprine

@JamesGawron, make sure that your "build" job actually archives the artifacts (it's a configurable post-build action) – Kelci

Ok, I wasnt archiving the artifacts, that is happening now. Seems to be going to this location ... JENKINS_ROOT/jobs/JOBNAME/builds/2013-11-26_12-09-43/archive/target/myJarName.war ... Deploy job is still unable to find the artifact however ... hard to tell where it is actually trying to look for it. – Caprine

It will take the archives from the job's archive location (you don't need to know the full path to it). The archive location preserves directory structure of the artifacts (in your case target/myJarName.war). When you reference to the artifact in "Copy Artifacts" step, use that same path. Or you can use */myJarName.war to avoid worrying about path. Or even **/.war (which will take any archived .war file. Finally, there is an option to "flatten directories", which will remove all directories after the copy and leave just the .war files (or whatever you selected) – Kelci

It won't let me edit after 5 minutes. It was supposed to be **/myJarName.war and **/*.war. @JamesGawron – Kelci

"Promote builds when..." missing? Then install the Promoted Builds Plugin. – Finnegan

Great descriptions there! I do have a question, how u guys deal with conflict branches? Say I have "feature_branch_1" and "feature_branch_2", branch_1 is promoted so it is merged to remote master, but branch_2 will fail to promoted because the conflict? – Beguine

@Beguine This particular answer deals with moving Artifacts of a Build job through to a promoted (Deploy) job. Your question seems to be about merging multiple (git?) branches in SCM. There is no way I can answer that within the character limit of comments section, without making a world of assumptions. You should make a new question detailing your situations, and you can link it here and I (and others) will definitely have a look. – Kelci

@Kelci I post a new thread here having more detail descriptions, Im not using "Copy Artifact plugin" yet, do u think that will help with my case? kinda lost here. – Beguine

@Beguine No, you are not dealing with artifacts in your situation. Rest of discussion there. – Kelci

Thanks for this nice tutorial, However for my case i have to downgrade the Parameterized Trigger Plugin to 2.25 to 2.22. – Anon

@AbhijeetKamble looks like version 2.23 made it mandatory to have parameters defined in the called job. Link here. So either modify the called job and create all required parameters (and possible values) there, or use the workaround they've listed to enable old behaviour. – Kelci

@Salv Thanks for the suggestion , will try again to implement the same with version 2.23. – Anon

@Kelci Thanks for such great help. i created the same setup as you explained. now the thing where i stuck is not able to create environment on remote machine as am deploying artifacts through scp and all the plugins which allow me to do remote ssh and run scripts are before the builds completes. please let me know in case you have any solution. Thanks in advance – Anon

@AbhijeetKamble It would be better if you'd create a specific question about your environment, and link it here, I will answer in that question to keep things clean. However if all that you are having trouble with is the order of step execution, then Flexible Publish plugin is what you need. – Kelci

@Kelci Added a question. please take a look #27198826 – Anon

great work with the guide. only this part "Configure a Build selector for Copy Artifact with name: BuildSelection" confused me a bit. I took quite a while to figure out, that an additional parameter of the spcial type "Build selector for Copy Artifact" is needed. Maybe you can clarify your guid – Slippy

@Slippy I had tried to signify parameter types by bolding them. Nonetheless, I've reworded the answer to take your suggestion. Thanks. – Kelci

Answer 2

Marked answer is great explanation for the question. But I would like to suggest a solution for those people looking for "how-to-promote-a-specific-build-number-from-another-job-in-jenkins"

We can use a generalized solution for doing force promotion using CURL and REST API. You can execute curl from Shell or Groovy scripts.

Shell Solution using CURL:

    user_name="jenkins_user"
    user_token="token" 
    promotion_name="Test_Promote"
    jenkins_url="http://build-server.com"
    JOB_NAME="job_name"
    JOB_NO="job-no"

    url="--silent -u $user_name:$user_token $jenkins_url/job/$JOB_NAME/$JOB_NO/promotion/forcePromotion?name=$promotion_name"
    curl $url


Groovy Soultion:
        user_name="jenkins_user"
        user_token="token" 
        promotion_name="Test_Promote"
        jenkins_url="http://build-server.com"
        JOB_NAME="job_name"
        JOB_NO="job-no"


def response = "curl -u $user_name:$user_token \" $jenkins_url/job/$JOB_NAME/$JOB_NO/promotion/forcePromotion?name=$promotion_name".execute().text

How to generate jenkins user token: https://jenkins.io/blog/2018/07/02/new-api-token-system/

Farseeing