[JENKINS-36089] Pipeline support for Promoted Builds Plugin

[jenkins-infra-bot]

This enhancement request is for the Promoted Builds plugin to support Jenkins' 2.X style Pipelines.

Pipelines are the new paradigm that Jenkins 2.X is promoting heavily – with its ability to define the build process in code, automatic build discovery, and great integration with repository systems for automatic build / testing of pull requests.

There are many places within the new Pipeline style where the Promoted Plugin could be used to great effect:

• builds could dynamically https://issues.jenkins-ci.org/browse/JENKINS-36089#promote and save artifacts, pushing them into other pipeline jobs
• Users could manually promote pipeline builds that have been through some kind of QA process
• Permalinks provided by the Promoted Builds plugin could be used in pipeline builds

Basically, the same vast number of use cases that the Promoted Build Plugin provides today could be taken advantage of by builds defined via the Pipeline API and Jenkinsfile build definitions.

Reference here for the API changes that are required for a plugin to be available in a Pipeline build:
https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md

Original reference bug:
https://issues.jenkins-ci.org/browse/JENKINS-35376

---

Originally reported by gregcovertsmith, imported from: Pipeline support for Promoted Builds Plugin

• status: Open
• priority: Major
• component(s): promoted-builds-plugin
• label(s): gsoc-2019-project-idea, gsoc2019-artifact-promotion-in-pipeline, pipeline, roadmap
• resolution: Unresolved
• votes: 154
• watchers: 169
• imported: 2025-12-07

Raw content of original issue

This enhancement request is for the Promoted Builds plugin to support Jenkins' 2.X style Pipelines.

Pipelines are the new paradigm that Jenkins 2.X is promoting heavily – with its ability to define the build process in code, automatic build discovery, and great integration with repository systems for automatic build / testing of pull requests.

There are many places within the new Pipeline style where the Promoted Plugin could be used to great effect:

	
builds could dynamically https://issues.jenkins-ci.org/browse/JENKINS-36089#promote and save artifacts, pushing them into other pipeline jobs
	
Users could manually promote pipeline builds that have been through some kind of QA process
	
Permalinks provided by the Promoted Builds plugin could be used in pipeline builds



Basically, the same vast number of use cases that the Promoted Build Plugin provides today could be taken advantage of by builds defined via the Pipeline API and Jenkinsfile build definitions.

Reference here for the API changes that are required for a plugin to be available in a Pipeline build:
https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md

Original reference bug:
https://issues.jenkins-ci.org/browse/JENKINS-35376

[jenkins-infra-bot]

jviolas:

• Original comment link
• Raw content of original comment:

  In the meantime, is there any workaround or best practice to have manual promotion on build with multibranch pipeline job ?
  

In the meantime, is there any workaround or best practice to have manual promotion on build with multibranch pipeline job ?

[jenkins-infra-bot]

gregcovertsmith:

• Original comment link
• Raw content of original comment:

  I am waiting on this feature, which will give me something close to promotion, using pipeline input:
  
  https://issues.jenkins-ci.org/browse/JENKINS-27039
  

I am waiting on this feature, which will give me something close to promotion, using pipeline input:

https://issues.jenkins-ci.org/browse/JENKINS-27039

[jenkins-infra-bot]

tealcosmo:

• Original comment link
• Raw content of original comment:

  Yes Please.  It's very hard to have build pipelines without some amount of manual promotion and testing before the next step. 
  

Yes Please. It's very hard to have build pipelines without some amount of manual promotion and testing before the next step.

[jenkins-infra-bot]

tdudala:

• Original comment link
• Raw content of original comment:

  This support would be very useful. Currently this is our major blocking point for moving into pipelines.
  

This support would be very useful. Currently this is our major blocking point for moving into pipelines.

[jenkins-infra-bot]

winotu:

• Original comment link
• Raw content of original comment:

  jviolas As a alternative you could try to add hyperlink in build description(with GET parameters) to some promotion job under certain statement that is needed for promotion.
  

jviolas As a alternative you could try to add hyperlink in build description(with GET parameters) to some promotion job under certain statement that is needed for promotion.

[jenkins-infra-bot]

jviolas:

• Original comment link
• Raw content of original comment:

  winotu: Thanks for the tip. I'll try that.
  Right now we didn't have to use promotion since we migrate to pipelines, but the time will come. If the plugin has not been updated then, I think we will create some jobs dedicated to promotion (publish artifacts and other specific actions) that will get all necessary artifacts from the main building jobs.
  

winotu: Thanks for the tip. I'll try that.
Right now we didn't have to use promotion since we migrate to pipelines, but the time will come. If the plugin has not been updated then, I think we will create some jobs dedicated to promotion (publish artifacts and other specific actions) that will get all necessary artifacts from the main building jobs.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  -1 on this. The design of Promoted Builds is bad. There could be a separate plugin offering comparable functionality but done the right way.
  

-1 on this. The design of Promoted Builds is bad. There could be a separate plugin offering comparable functionality but done the right way.

[jenkins-infra-bot]

rgreig:

• Original comment link
• Raw content of original comment:

  Can you expand on why the design of promoted builds is bad?
  
  I am using multibranch pipelines, and would like to be able to have automated deployments through different environments, but only with human approval. Is there a recommended approach for achieving this? I confess I did not understand the suggestion above of adding a hyperlink.
  

Can you expand on why the design of promoted builds is bad?

I am using multibranch pipelines, and would like to be able to have automated deployments through different environments, but only with human approval. Is there a recommended approach for achieving this? I confess I did not understand the suggestion above of adding a hyperlink.

[jenkins-infra-bot]

maxzilla:

• Original comment link
• Raw content of original comment:

  I just wanted to explain my approach for promoting pipeline builds, maybe it helps others.
  
  I have several components and each has a separate build job. All jobs are orchestrated by a build chain job which triggers the other jobs, runs integration tests, etc. 
  
  After the build chain completed successfully, I use GroovyPostbuildAction.createBadge() to add a badge to the builds that were used during the integration tests.
  
  Then I created a promotion job, in which I can select the component and the build number to promote. It then checks if that specific build contains the badge that was previously added (i.e. all tests were successful) and does some action (deploy on production server, upload artifacts, ...).
  
  In the promotion job, I also included mechanisms to implement multi-level promotion by using different badges, so that, for example, a release first has to be deployed on the testing servers before it may be deployed to production systems.
  

I just wanted to explain my approach for promoting pipeline builds, maybe it helps others.

I have several components and each has a separate build job. All jobs are orchestrated by a build chain job which triggers the other jobs, runs integration tests, etc.

After the build chain completed successfully, I use GroovyPostbuildAction.createBadge() to add a badge to the builds that were used during the integration tests.

Then I created a promotion job, in which I can select the component and the build number to promote. It then checks if that specific build contains the badge that was previously added (i.e. all tests were successful) and does some action (deploy on production server, upload artifacts, ...).

In the promotion job, I also included mechanisms to implement multi-level promotion by using different badges, so that, for example, a release first has to be deployed on the testing servers before it may be deployed to production systems.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  I am using multibranch pipelines, and would like to be able to have automated deployments through different environments, but only with human approval. Is there a recommended approach for achieving this?
  
  input step generally, assuming only the last build to pass tests is eligible for approval. Otherwise there is no equivalent currently. No plans to use the Promoted Builds plugin as is; needs to be redesigned from scratch.
  

I am using multibranch pipelines, and would like to be able to have automated deployments through different environments, but only with human approval. Is there a recommended approach for achieving this?

input step generally, assuming only the last build to pass tests is eligible for approval. Otherwise there is no equivalent currently. No plans to use the Promoted Builds plugin as is; needs to be redesigned from scratch.

[jenkins-infra-bot]

jviolas:

• Original comment link
• Raw content of original comment:

  In my case, I have some jobs building/testing various applications for different platform. I created one job specific for promotion. This job has parameters that let user choose the build for each job he wants to promote. The job then copy the artifacts of each build, do some checking to be sure the selected build is a valid one to be promoted and then publish the artifacts. This jobs also archive the artifacts as its own, so I can find promoted artifacts easily.
  
  The only thing I lost comparing to before with the Promoted builds Plugin is the badge in the description of the promoted build that helps finding the last promoted build, but now I can find then in my promotion job, in which I have only the promoted artifacts.
  

In my case, I have some jobs building/testing various applications for different platform. I created one job specific for promotion. This job has parameters that let user choose the build for each job he wants to promote. The job then copy the artifacts of each build, do some checking to be sure the selected build is a valid one to be promoted and then publish the artifacts. This jobs also archive the artifacts as its own, so I can find promoted artifacts easily.

The only thing I lost comparing to before with the Promoted builds Plugin is the badge in the description of the promoted build that helps finding the last promoted build, but now I can find then in my promotion job, in which I have only the promoted artifacts.

[jenkins-infra-bot]

oleg_nenashev:

• Original comment link
• Raw content of original comment:

  I still disagree with jglick regarding the Promoted Builds feasibility for Pipeline. Honestly conditional promotion of releases is a PITA in Pipeline now, but I agree that the Promoted builds plugin ideally needs some redesign before adding the Pipeline support.
  
  My vision:
  
  	
  Get rid of the built-in promotion job, use standalone one (of any time, not just Freestyle-alike)
  	
  In standalone jobs introduce the "Environment" entity to indicate where the build results are being deployed
  	
  Get rid of the access to workspaces, allow promoting only artifacts (with some flexibility via build steps, of-course)
  	
  Use Fingerprinting to trace artifacts between original and promotion jobs
  	
  Retain the promotion functionality for cross-referencing builds and for triggering promotions from jobs
  	
  Actually retain almost all existing UIs...
  
  
  
  That's how I see it, the implementation would be more or less close to what is implemented in AppVeyor.
  
  Bad news is that I won't have personal time to work on it in middle-term. Any contributions will be appreciated 
  

I still disagree with jglick regarding the Promoted Builds feasibility for Pipeline. Honestly conditional promotion of releases is a PITA in Pipeline now, but I agree that the Promoted builds plugin ideally needs some redesign before adding the Pipeline support.

My vision:

• Get rid of the built-in promotion job, use standalone one (of any time, not just Freestyle-alike)
• In standalone jobs introduce the "Environment" entity to indicate where the build results are being deployed
• Get rid of the access to workspaces, allow promoting only artifacts (with some flexibility via build steps, of-course)
• Use Fingerprinting to trace artifacts between original and promotion jobs
• Retain the promotion functionality for cross-referencing builds and for triggering promotions from jobs
• Actually retain almost all existing UIs...

That's how I see it, the implementation would be more or less close to what is implemented in AppVeyor.

Bad news is that I won't have personal time to work on it in middle-term. Any contributions will be appreciated

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Get rid of the built-in promotion job, use standalone one
  
  Yes this is the key. The number of the upstream build being “promoted” should simply be passed as a build parameter to the downstream build. Of course you can do this today without the UI.
  
  I do not think other concepts of the existing plugin are particularly problematic (though, as mentioned, certain common use cases are done more simply in a single Pipeline job).
  

Get rid of the built-in promotion job, use standalone one

Yes this is the key. The number of the upstream build being “promoted” should simply be passed as a build parameter to the downstream build. Of course you can do this today without the UI.

I do not think other concepts of the existing plugin are particularly problematic (though, as mentioned, certain common use cases are done more simply in a single Pipeline job).

[jenkins-infra-bot]

gregcovertsmith:

• Original comment link
• Raw content of original comment:

  Today, I am using "Keep this build forever" as a "poor man's" promotion button.
  
  I have a pipeline script that runs every 15 minutes, and searches for builds that have been marked "Keep Forever" and then passes their information / build number to the next build in the promotion.
  
  Its not as flexible as the Promoted Builds plugin was originally, but its working well.
  
  My only wish is that I could trigger that build off new builds being marked "Keep Forever" instead of requiring that it run polling every 15 minutes.
  
  This is just FYI – as I thought it might be interesting to someone else who finds this jira issue.
  

Today, I am using "Keep this build forever" as a "poor man's" promotion button.

I have a pipeline script that runs every 15 minutes, and searches for builds that have been marked "Keep Forever" and then passes their information / build number to the next build in the promotion.

Its not as flexible as the Promoted Builds plugin was originally, but its working well.

My only wish is that I could trigger that build off new builds being marked "Keep Forever" instead of requiring that it run polling every 15 minutes.

This is just FYI – as I thought it might be interesting to someone else who finds this jira issue.

[jenkins-infra-bot]

stevenarmstrong:

• Original comment link
• Raw content of original comment:

  To give a use case, we have common ci builds for the following:
  networking ci build (governs acl rules)
  load balancing ci build (governs load balancer config)
  platform image ci build (governs centos/ windows images)
  developer specific ci build (code compilation). 
  
  Each of these ci builds have an associated promoted build parameter which when they are successful increments without teams having to manually update dependencies when a check-ins occur to networking, platform or load balancing versions. 
  
  These ci builds then roll up into a "package build" which generates the build artifact used at deployment time (we build a manifest json file using the artifacts linked to the latest promoted build parameter versions). This is generated every developer check-in and deployment pipelines are then invoked by the new manifest release candidate. 
  This manifest json then consumes the latest networking, load balancing, platform image using promoted build parameters to pull all the necessary artifacts from each ci build and arrange them as the 1st deployment step in the deployment pipeline. 
  
  Currently not having the promoted build parameter plugin integrated with the pipeline job type means we cant currently make the package build, currently a freestyle job, the 1st step of the jenkinsfile pipeline job and then trigger other jenkinsfile pipeline jobs from it using promotion stars, as it traverses environments. 
  
  With the promoted build parameter missing from the pipeline job we are missing the ability to:
  
  1) Associate the promoted build parameters with the pipeline job type as part of the jenkinsfile meaning the pipeline jenkinsfile cant be stored in the code repository and used as the trigger event for the quality assurance pipeline. 
  2) Trigger a pipeline based on a state change to an artifact repository or another build. Currently we use thoughtworks go for pipelines, which allows us to push the manifest file to artifactory and then poll the repository for changes. The urltrigger plugin could provide this feature as well but it also hasnt been converted to the pipeline job type either meaning we currently have no way to trigger pipelines based on an artifact change. An updated promoted build number could be used to act as that trigger rather than the external artifact.
  3) We will want to have a jenkinsfile for each pipeline stage so qa, integration, perf and prod by having association between multiple jenkinsfiles is necessary, the promoted build plugin could potentially do this link, so each pipeline promotes a package (promoted build number) that is allowed to be deployed to the next environment by users. This is particularly useful in continuous delivery when in production environments teams can select a promoted build number to deploy the latest build or trigger a previous promoted build number to roll back by selecting it from the dropdown list.
  
   The above points are currently blocking us from moving to jenkins 2.x for pipelines from thoughtworks go and probably preventing many others too.
  

To give a use case, we have common ci builds for the following:
networking ci build (governs acl rules)
load balancing ci build (governs load balancer config)
platform image ci build (governs centos/ windows images)
developer specific ci build (code compilation).

Each of these ci builds have an associated promoted build parameter which when they are successful increments without teams having to manually update dependencies when a check-ins occur to networking, platform or load balancing versions.

These ci builds then roll up into a "package build" which generates the build artifact used at deployment time (we build a manifest json file using the artifacts linked to the latest promoted build parameter versions). This is generated every developer check-in and deployment pipelines are then invoked by the new manifest release candidate.
This manifest json then consumes the latest networking, load balancing, platform image using promoted build parameters to pull all the necessary artifacts from each ci build and arrange them as the 1st deployment step in the deployment pipeline.

Currently not having the promoted build parameter plugin integrated with the pipeline job type means we cant currently make the package build, currently a freestyle job, the 1st step of the jenkinsfile pipeline job and then trigger other jenkinsfile pipeline jobs from it using promotion stars, as it traverses environments.

With the promoted build parameter missing from the pipeline job we are missing the ability to:

1) Associate the promoted build parameters with the pipeline job type as part of the jenkinsfile meaning the pipeline jenkinsfile cant be stored in the code repository and used as the trigger event for the quality assurance pipeline.
2) Trigger a pipeline based on a state change to an artifact repository or another build. Currently we use thoughtworks go for pipelines, which allows us to push the manifest file to artifactory and then poll the repository for changes. The urltrigger plugin could provide this feature as well but it also hasnt been converted to the pipeline job type either meaning we currently have no way to trigger pipelines based on an artifact change. An updated promoted build number could be used to act as that trigger rather than the external artifact.
3) We will want to have a jenkinsfile for each pipeline stage so qa, integration, perf and prod by having association between multiple jenkinsfiles is necessary, the promoted build plugin could potentially do this link, so each pipeline promotes a package (promoted build number) that is allowed to be deployed to the next environment by users. This is particularly useful in continuous delivery when in production environments teams can select a promoted build number to deploy the latest build or trigger a previous promoted build number to roll back by selecting it from the dropdown list.

The above points are currently blocking us from moving to jenkins 2.x for pipelines from thoughtworks go and probably preventing many others too.