Export to GitHub

build-pipeline-plugin - issue #54

Add support for manual parameterized builds


Posted on Jul 7, 2011 by Quick Hippo

Under "Build Pipeline Plugin -> Manually Execute Downstream Project" there is only an option to specify the build names. It would be nice to be able to add build parameters as well, so that we could manually trigger parameterized builds.

For example, I have a job that builds a war file for my application. I also have a parameterized job that will deploy a given application to a given environment. I would like to add the deployment job as a manual build, but right now there is no way to specify the application or environment parameters.

Attachments

Comment #1

Posted on Jul 22, 2011 by Happy Rhino

Are you thinking something like being able to have a list of servers to choose from as the target server to deploy to?

I'd find that useful too.

Wouldn't the triggered job be the correct place to add parameterization (e.g. a choice parameter) though?

Comment #2

Posted on Aug 30, 2011 by Helpful Wombat

Having the same issue. I have a job building a WAR (job A) and a manual downstream job (job B) to build RPM and deploy to different environments. At the moment i have no chance to pass the buildnumber of job A to job B so i can fetch the correct war files for further processing.

Comment #3

Posted on Aug 30, 2011 by Happy Elephant

Here's how to workaround this problem (unfortunately by not using the build-pipeline-plugin): http://stackoverflow.com/questions/5243593/how-to-trigger-a-build-only-if-changes-happen-on-particular-set-of-files/5371266#5371266 describes how to use Jenkins CLI to trigger parameterized downstream jobs.

This is really a blocker for me, I'd love to use build-pipeline-plugin but can't.

Comment #4

Posted on Aug 30, 2011 by Happy Monkey

We're using the Parameterized Trigger Plugin in conjunction with the build pipeline and it clips together nicely for passing stuff downstream (in our case, generated facts like timestamps and SCM tags).

However it won't do what I think the OP is asking for i.e. an interstitial dialog box.

Comment #5

Posted on Aug 31, 2011 by Quick Lion

I think this is similar to issue 53

Comment #6

Posted on Nov 27, 2011 by Grumpy Hippo

Issue 53 has been merged into this issue.

Comment #7

Posted on Nov 27, 2011 by Grumpy Hippo

1.2.4 is available for manual download and testing: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin+-+Roadmap

Comment #8

Posted on Nov 27, 2011 by Grumpy Hippo

1.2.4 is available for manual download and testing: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin+-+Roadmap

Comment #9

Posted on Nov 27, 2011 by Grumpy Hippo

1.2.4 is available for manual download and testing: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin+-+Roadmap

Comment #10

Posted on Nov 27, 2011 by Grumpy Hippo

1.2.4 is available for manual download and testing: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin+-+Roadmap

Comment #11

Posted on Feb 29, 2012 by Grumpy Dog

We are missing this feature here also!

Our scenario is, that we have a history of integration-builds, integrating one user-story after the others. We want to create a buildpipeline, which reaches a manual step to deploy to the qs system.

Our qs people travel around the build-runs and want to click on "deploy this to qs" in order to deploy the artifacts of the specific build to the qs-system. This implies, that clicking the "deploy" after build-run #45 should deploy the artifacts of #45 and clicking "deploy" after build-run #46 should deploy the artifacts of #46.

What I am wondering about is, this code, which i found in the class BuildPipelineView in the method triggerManualBuild:

// Get parameters from upstream build final Action buildParametersAction = BuildUtil.getAllBuildParametersAction(upstreamBuild, triggerProject); return triggerBuild(triggerProject, upstreamBuild, buildParametersAction);

Shouldn't this code take care of passing the Parameters to the downstream job?

Comment #12

Posted on May 29, 2012 by Helpful Elephant

I would like to TAG my whole pipeline, but the name of the TAG is known only when button is going to be pushed.

There is another way to do this using this plugin? In other words, there is a way to fill out a parameter every time the button is pushed?

Comment #13

Posted on Jun 8, 2012 by Massive Elephant

Another vote for this issue, or more specifically issue #53 that was merged into it, that as written is exactly my concern as well.

We need a way to be able to interact with build parameters (i.e. set with the "This build is parameterized" configuration) of a manually triggered downstream job, so that it displays the "This build requires parameters:" display showing the parameters and their defaults before running the triggered job, so that they can be changed on the fly as necessary, just as it would if you kicked of that same job via a "Build Now".

Is this truly not possible?

Comment #14

Posted on Jun 13, 2012 by Swift Camel

Comment deleted

Comment #15

Posted on Jun 13, 2012 by Swift Camel

use this https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

Comment #16

Posted on Jun 13, 2012 by Massive Elephant

The Parameterized Trigger Plugin doesn't seem to be what I'm looking for. I want the to see the parameters before the job runs and be able to manually change them when I trigger the job, just as one can when you do a Build Now.

Comment #17

Posted on Jun 13, 2012 by Swift Camel

Comment deleted

Comment #18

Posted on Jun 13, 2012 by Swift Camel

Comment deleted

Comment #19

Posted on Jun 13, 2012 by Swift Camel

Yes just discovered this doesn't work with manual execution in a pipeline, very annoying. This is a major gap.

Comment #20

Posted on Jun 30, 2012 by Happy Rabbit

For those interested, i created a patch that integrates the parameterized-trigger plugin with the build pipeline job. It adds the ability to configure parameters for manually executed downstream jobs. I'll try and contact the centrum system guys to see if we I can get this into the mainline. If in the mean time someone would like to test it out, or look at the code (I haven't done any jenkins plugin development before, so i am sure there's stupid mistakes in there) I would be much obliged

Sources : https://bitbucket.org/jelmerk/build-pipeline-plugin Binary : https://bitbucket.org/jelmerk/build-pipeline-plugin/downloads/build-pipeline-plugin.hpi Patch : https://bitbucket.org/jelmerk/build-pipeline-plugin/changeset/5624ec2d686c

Comment #21

Posted on Jun 30, 2012 by Swift Panda

Setting status to Accepted, as this is clearly a sensible (and even popular) feature.

Comment #22

Posted on Jun 30, 2012 by Massive Elephant

My concern about this patch is that if I am still unable to manually change the parameters before the job runs this doesn't really solve any problems for me.

Comment #23

Posted on Jun 30, 2012 by Happy Rabbit

Hey, Dankirkd , you are right. that's another issue altogether.

I wouldn't mind adding that feature as well since it's clearly useful. but I am concerned that my patch will then do too much which might make it hard to get it accepted.

And if i make it into another patch then it will conflict with this patch

Comment #24

Posted on Jun 30, 2012 by Massive Elephant

But can't we already do what you're adding? Any job can take parameters as configured for that job, and these can be part of a build pipeline, which simply picks up the defaults one has set. The problem seems to be that one can't alter them. I don't understand what the original author of this issue wasn't able to do that way?

Comment #25

Posted on Jun 30, 2012 by Happy Rabbit

I created the patch in particular so that things like svn revisions and git commit id's can be passed down to downstream jobs.

What the build pipeline plugin does by default is copy (and merge) the ParametersAction but not things like RevisionParameterAction

Comment #26

Posted on Jun 30, 2012 by Massive Elephant

Then it sounds like you're addressing a different problem. Unfortunately the original author of this issue has never chimed in further to clarify his problem, but as I read it, I'm not sure how your patch will resolve it.

Comment #27

Posted on Aug 13, 2012 by Swift Horse

please include the patch from jelmerk's fork above!

Comment #28

Posted on Aug 15, 2012 by Grumpy Hippo

Hey guys,

Sorry it is taking us a while to get this resolved. We'd welcome the fix if someone could provide it.

Jelmerk, if you'd like us to bring in your fix, would you be able to make it in a clone of this project so that we can more easily integrate it. Thanks.

Also, the following might solve some peoples issues. If you want a unique reference (such as the build number of the 1st job, or the SCM revision etc) that you can pass down the pipeline to retrieve artefacts or check out a consistent version, if you set a parameter in one of the upstream jobs it will be available to the downstream ones. So you could do something like this in your first job of the pipeline using a System Groovy script and the groovy plugin (obviously using a unique ID relevant to your set up):

import hudson.model.AbstractBuild import hudson.model.ParametersAction import hudson.model.StringParameterValue

def currentBuild = Thread.currentThread().executable; def newParamAction = new ParametersAction(new StringParameterValue("MY_PIPELINE_IDENTIFIER","77")); currentBuild.addAction(newParamAction);

It will be available to all your downstream jobs...

Comment #29

Posted on Aug 15, 2012 by Happy Rabbit

Hi Geoff, I am not sure what it is you are asking of me when you say you want me to make a clone of this project, the patch is already in a mercurial fork of your repository.

I attached a patch that should apply cleanly to the current development version

Attachments

Comment #30

Posted on Aug 17, 2012 by Grumpy Hippo

Jelmerk, I've added you as a committer to the project so that you can incorporate your change.

Details coming separately...

Comment #31

Posted on Aug 17, 2012 by Massive Elephant

Once this patch is incorporated it would be nice if we could revisit the above thread conversation at comment 22. I'm still not convinced the patch addresses the problem issue #54 was created for, and it doesn't address the problem of manually changing parameters before the job runs as one can do if run standalone, which was issue #53, which I believe was mistakenly marked as a duplicate of this issue.

Comment #32

Posted on Aug 17, 2012 by Massive Bird

agree with dankirkd, issue 53 is exactly the what i want

Comment #33

Posted on Aug 28, 2012 by Massive Bird

Jkupe...@gmail.com really solved this ticket but issue 53 is really a different ticket. I suggest we close this ticket with Jkupe's solution. Then reopen ticket 53, which is different since it needs manually change within build pipe line view rather than predefined in upstream project configuration.

Comment #34

Posted on Aug 29, 2012 by Swift Horse

I'm currently using that fork from jelmerk. the parameterized manual build seems to work fine when triggering the build directly after the main build of the pipeline, but not when later in the queue. :(

my setup: MAIN -> Deploy -> Deploy-UAT (manually) -> Release (manually) -> Tests -> tests2 (manually)

Triggering tests2 worked just fine. But Deploy-UAT always uses default parameters! :(

Comment #35

Posted on Aug 29, 2012 by Swift Horse

oh, the descrbed problem is a little different:

my setup: HEAD -> Deploy -> Deploy-UAT (manually) -> Release (manually) -> Tests

BRANCH1 -> Deploy -> Deploy-UAT (manually) -> Release (manually) -> BRANCH-Tests

There seems to be a problem when triggering a manual job that is reffered by two (or more) build jobs.

The Deploy job is getting the correct build parameters. But when triggering the Deploy-UAT from the BRANCH pipeline, it will alway try to deploy HEAD #1 which is the on Deploy-UAT default too.

Too bad :( Otherwise this would be a really cool use case, since the deployment code shouldnt change too much. ;)

Comment #36

Posted on Sep 24, 2012 by Swift Bird

Hi - we would really like to have this feature too - is there any progress?

Comment #37

Posted on Oct 17, 2012 by Quick Elephant

The current HEAD including this patch did not work for me.

  • "Add parameters" appears, but no options are listed.
  • After fixing that, the parameters are overwritten by default parameters, from buildParametersAction.
Attachments

Comment #38

Posted on Oct 20, 2012 by Quick Elephant

My patch in comment 37 is now committed to the repository HEAD.

Comment #39

Posted on Dec 18, 2012 by Helpful Elephant

There were any improvement in the implementation of this issue?

Comment #40

Posted on Dec 28, 2012 by Grumpy Wombat

Another +1 for this feature.

Our use case is that we have many deployment environments which use common deployment child jobs that are called from top level jobs where all the environment parameters are defined. Our current workflow just calls each subsequent step as a parameterized trigger of another job so all the env setup only needs to be defined once in the parent job. I spent some time attempting to setup the same scenario using the pipeline plugin and the lack of environment preservation from one job to the next is a deal breaker for us.

Comment #41

Posted on Jan 8, 2013 by Grumpy Dog

Another +1 for this feature. Test with the version 1.3.4-SNAPSHOT but that didn't work for me

Comment #42

Posted on Jan 18, 2013 by Happy Dog

Guys, I'm getting the following error when trying to build from head: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.4:compile (default-compile) on project build-pipeline-plugin: Compilation failur e: Compilation failure: [ERROR] C:\Downloads\build-pipeline-plugin-a3e3114cb4e1\src\main\java\au\com\centrumsystems\hudson\plugin\buildpipeline\BuildPipelineView.java:[470,101] inconve rtible types [ERROR] found : hudson.util.RunList [ERROR] required: java.util.List> [ERROR] C:\Downloads\build-pipeline-plugin-a3e3114cb4e1\src\main\java\au\com\centrumsystems\hudson\plugin\util\BuildUtil.java:[60,118] inconvertible types [ERROR] found : hudson.util.RunList [ERROR] required: java.util.List>

WHat am I doing wrong? Any help please - really need this feature :)

Comment #43

Posted on Jan 21, 2013 by Happy Elephant

I just ran mvn install and mvn hpi:run from the latest and it ran OK, so I'm not sure...

Maybe it's worth trying deleting your local repo. What version of the JDK do you have??

Comment #44

Posted on Jan 22, 2013 by Happy Dog

Hi Geoff, thanks for reply. Cleaning up local repo didn't help. JDK version is 1.6.0_07. Am I supposed to build it on 7th?

Comment #45

Posted on Jan 22, 2013 by Grumpy Hippo

No, that should be fine...

Send me full log and print out your environment and I'll see if I can spot anything. I send you an email.

Anyone else able to try and recreate???

Comment #46

Posted on Feb 5, 2013 by Grumpy Camel

One of the final steps of my build pipeline is to execute a (manual) release. In order to execute a release I need to manually pass two parameters: release version and new development version. If I run that specific job independently ("Build Now") then Jenkins prompts me for the parameters. However, if I press the "Trigger" button for that step in the pipeline, then the job just starts but never prompts me for the parameters. I cannot find a workaround for what I need to do. This feature is really required... Thanks

Comment #47

Posted on Feb 6, 2013 by Massive Elephant

Comment deleted

Comment #48

Posted on Feb 6, 2013 by Massive Elephant

Mario - your scenario is the same as mine. The workaround I have to use is to modify the defaults for the parameters to what I would have set them to via the pipeline so that they are picked up when I trigger it through the pipeline. Not an elegant solution, but it is a workaround. Doesn't work of course if you don't have permissions to modify the configuration.

Comment #49

Posted on Feb 6, 2013 by Quick Elephant

dankirkd - I had thought about that. The problem with that approach is that if the trigger button is pressed twice without previously changing the parameters (quite likely indeed) the original SVN tag will be overwritten with the new codebase. This is quite dangerous. I am researching if I can make the job check some pre-conditions before actually running the promotion. Thanks for your help!

Comment #50

Posted on Feb 6, 2013 by Swift Bird

Comment deleted

Comment #51

Posted on Feb 6, 2013 by Swift Bird

I currently use Build Pipeline to manage/view some Build Flow jobs, and I've noticed a potentially easier work around than what I've seen in the last few comments. I have two flows: Dev-Flow (which is automatically triggered by the upstream individual compile jobs); and Test-Flow, which is tied to Dev-Flow as 'Manually Execute Downstream Project'.

From the Build Pipeline view, when I click on the manual trigger for Test-Flow, following a successful Dev-Flow, the first job always fails, and no information is passed between the two. When I click it a second a time, the "upstream" information is passed, and Test-Flow picks it up with this DSL:

build( "Deploy", CONTEXT_PATH: upstream.buildVariables.CONTEXT_PATH, INITIAL_JOB_NAME: upstream.buildVariables.INITIAL_JOB_NAME, INITIAL_BUILD_NUMBER: upstream.buildVariables.INITIAL_BUILD_NUMBER)

These are explicit parameters that I've defined upstream, so, you may need to pass any of Jenkins's own ENV parameters to your own parameter (i.e., THE_SVN_REV_I_REALLY_CARE_ABOUT) and continue to define that parameter for each step.

Comment #52

Posted on Mar 12, 2013 by Happy Hippo

I've been using 1.3.4-SNAPSHOT for a while now and I feel it solves the issue and would like to have the version finalized and issue solved. But it does not solve issue 53 which could be reopened. Issue 53 clearly describes that a manual input should take place. This one does not(?).

This is how I use 1.3.4-SNAPSHOT now: 1. Build 2. Manual trigger parametrized build sending build number as so BUILD_SELECTOR=$BUILD_NUMBER 3. Parameterized build takes one param BUILD_SELECTOR 4. Parameterized build copies artifact from triggered build from BUILD_SELECTOR (Copy Artifact Plugin) 5. Runs deployment of artifact

This works for now, but it would of course be useful to have manual input (issue 53). Alternative to build_selector could be sending revision number. Relasing and picking release-version number would require relying on automatic bumping or committing final versions to your repo before triggering I would guess.

Comment #53

Posted on Apr 16, 2013 by Happy Ox

For a pipeline plugin, it is very crucial to provide the feature of manually triggering a downstream job with a prompt for the input parameters, how they are defined in the build job (which is triggered).

When can we expect this feature?

Comment #54

Posted on Apr 18, 2013 by Happy Dog

Same question from me. We need manual trigerring with user-specified parameters. Can we expect this any time soon?

Comment #55

Posted on Apr 18, 2013 by Helpful Elephant

I've been waiting this for years

Comment #56

Posted on Apr 18, 2013 by Happy Hippo

Seems like this repo is moved and no longer maintained. From the frontpage:

"So, we will be moving back to the Jenkins ecosystem in April 2013. Unfortunately we won't be able to bring the issues across, so we will leave them here for reference.."

Seems perhaps it has been moved here: https://issues.jenkins-ci.org/browse/JENKINS/component/15962

Although it doesn't seem to be much signs of life there.

Last commit to the source code here was by Kohsuke March 3.

My opinion is that this issuesystem and maintaining the site on http://wiki.jenkins-ci.org is cumbersome and should be replaced by a Github repo. Ref issue #160 which I added.

I wonder if any developers are watching or maintaining this repo at all.

Comment #57

Posted on Apr 18, 2013 by Massive Elephant

Interesting. Kohsuke made a ton of changes - far more than the main committers have since the last release. I've been trying to get Centrum Systems people to deal with issues that were introduced with the last release July 2012, and to look at code since September. Not a peep.

They want more people to contribute, but they seem to put in the time themselves and don't keep us informed about what's going on. Very frustrating.

Comment #58

Posted on Apr 18, 2013 by Happy Rabbit

Adding my voice to the chorus

Comment #59

Posted on Apr 18, 2013 by Happy Hippo

Update on issue #160, seems like the GitHub-repo exists. https://github.com/kohsuke/build-pipeline-plugin

Comment #60

Posted on Apr 19, 2013 by Massive Elephant

I meant to write "they don't seem to".

Comment #61

Posted on May 31, 2013 by Quick Cat

Guys, this is a huge issue for us. With have about 30 application jobs all reusing a parameterized deploy-uat downstream job, but only the first downstream job actually has the upstream parameters (using the groovy script workaround). The others don't have access to them.

That means that currently, we're duplicating the deploy-uat project (and three other environments) per application job.

In other words, 30 app-jobs * 4 deploy-env jobs = 120 jobs, just to manually deploy using the pipeline plugin. 120 instead of 4 jobs. We need this functionality. We're considering a move to Bamboo because of this limitation.

Comment #62

Posted on May 31, 2013 by Quick Cat

Added a ticket on Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-18162 as well as on the Github repo issue tracker: https://github.com/jenkinsci/build-pipeline-plugin/issues/2

Comment #63

Posted on Jul 2, 2013 by Helpful Dog

not sure if this is a workaround for your problem, but i used two small curl-calls to retrieve missing parameters via the JSON-API from the upstream build of my manual build:

export UPSTREAM_BUILD_NR=$(curl ${BUILD_URL}/api/json|grep -Eo 'upstreamBuild":[0-9]+'|grep -Eo "[0-9]+"|tr -d ' ') UPSTREAM_SVN_REVISION=$(curl "${JENKINS_URL}/job/upstreamjobname/${UPSTREAM_BUILD_NR}/api/json" | grep -Eo 'SVN_REVISION","value":"[0-9]+"'|grep -Eo '[0-9]+')

Comment #64

Posted on Jul 2, 2013 by Happy Bear

I looked up the /api/json for both deploy builds and noticed that the parameters are the same despite being triggered by different upstream builds in two seperate pipelines.

Also, I noticed the build-pipeline plugin modified the tag of the downstream project during the first deploy build, but with the second the publisher tag is left unmodified.

In effect, the downstream project deployed the same application twice.

Comment #65

Posted on Mar 26, 2014 by Helpful Rabbit

We need this too.

Comment #66

Posted on Jul 16, 2014 by Swift Rabbit

Issue is still present. Please vote for it here: https://issues.jenkins-ci.org/browse/JENKINS-19121

Br, Jonas

Status: Accepted

Labels:
Type-Defect Priority-Medium