
build-pipeline-plugin - issue #53
Build with parameter does not work if the parameterized job is not the first one
What steps will reproduce the problem? 1.Create a pipeline with 2 jobs 2.Make the second job as parameterized build
What is the expected output? What do you see instead? It should ask for the parameter when the build is triggered, but it does not. But it asks for parameter if the first job is parameterized.
What version of the product are you using? On what operating system? 1.2.2 on Ubuntu 10.04
Please provide any additional information below.
Is it the expected behaviour, is it a bug with the plugin?
Comment #1
Posted on Jul 9, 2011 by Helpful RhinoThis is important, as one useful thing you can do with parameterized builds is pass a revision number to the next build to be sure that it works on the same source code. But currently, if you do this, the build pipeline plugin won't show it.
Comment #2
Posted on Jul 29, 2011 by Happy ElephantThis seems to be a limitation of the Parameterized Build Plugin:
"Limitations Currently the following are the known problems:
When build triggers are used to start a build, there's no way to pass parameters. This includes SCM polling, downstream builds, and periodic builds. Instead, the specified default values will be used for string, boolean and choice parameters." [http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build#ParameterizedBuild-Limitations]
Comment #3
Posted on Aug 31, 2011 by Quick LionI think something like this should be enabled. Here's an example:
- Commit Stage build (automatic) Checks out project from SCM - builds artifact.
- Integration test build (automatic) Uses build artifact from commit stage - here it needs some version info, i.e. some parameter passed from the build before
- Deploy to QA (manually triggered by QA department) Here the version parameter is needed again.
Maybe there's another way to achieve this?
Comment #4
Posted on Sep 27, 2011 by Helpful DogYes, we do need a way to pass parameters/values from an upstream job downstream
Comment #5
Posted on Nov 27, 2011 by Grumpy Hippo(No comment was entered for this change.)
Comment #6
Posted on Nov 27, 2011 by Grumpy Hippo1.2.4 is available for manual download and testing: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin+-+Roadmap
Comment #7
Posted on Nov 27, 2011 by Grumpy Hippo1.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 Hippo1.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 Hippo1.2.4 is available for manual download and testing: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin+-+Roadmap
Comment #10
Posted on Jun 13, 2012 by Swift Cameluse this https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin
Comment #11
Posted on Jul 24, 2012 by Massive BirdParameterized Trigger is not an acceptable workaround for that. It doesn't enable to manually set the parameter on the second(and after) builds
Comment #12
Posted on Jul 24, 2012 by Massive ElephantI agree. This problem is the number one failing I have with the pipeline plugin. All our downstream jobs take parameters, but when we trigger them through the pipeline we have to settle for the defaults, or change the defaults before triggering them, because we cannot manually change the parameter values, as one normally could if you triggered the job outside the pipeline. It shouldn't matter that the job was triggered in a pipeline, but for some reason it does.
Comment #13
Posted on May 31, 2013 by Quick CatGuys, 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 and we're currently considering a move to Bamboo because of this limitation.
Comment #14
Posted on Jul 29, 2013 by Helpful DogDoes anyone have a solution to this?
Comment #15
Posted on Nov 7, 2013 by Swift BearSame issue here... :(
Comment #16
Posted on Nov 14, 2013 by Swift BearJust notice that this is a 2 years old issue.
Comment #17
Posted on Jul 16, 2014 by Swift RabbitIssue is still present. Please vote for it here: https://issues.jenkins-ci.org/browse/JENKINS-19121
Br, Jonas
Status: Duplicate
Labels:
Type-Defect
Priority-Medium