Add support for manual parameterized builds

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by livermo...@gmail.com on 7 Jul 2011 at 8:14

Attachments:

• [Screen shot 2011-07-07 at 3.14.18 PM.png](https://storage.googleapis.com/google-code-attachments/build-pipeline-plugin/issue-54/comment-0/Screen shot 2011-07-07 at 3.14.18 PM.png)

[GoogleCodeExporter]

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.

Original comment by zacharys...@gmail.com on 6 Feb 2013 at 3:44

[GoogleCodeExporter]

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=<SpecificBuildSelector><buildNumber>$BUILD_NUMBER</buildNumber></
SpecificBuildSelector>
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.

Original comment by judoole on 12 Mar 2013 at 9:50

[GoogleCodeExporter]

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?

Original comment by michael....@googlemail.com on 16 Apr 2013 at 6:35

[GoogleCodeExporter]

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

Original comment by alexande...@gmail.com on 18 Apr 2013 at 11:25

[GoogleCodeExporter]

I've been waiting this for years

Original comment by fernando...@gmail.com on 18 Apr 2013 at 11:31

[GoogleCodeExporter]

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.

Original comment by judoole on 18 Apr 2013 at 12:05

[GoogleCodeExporter]

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.

Original comment by dankirkd@gmail.com on 18 Apr 2013 at 3:59

[GoogleCodeExporter]

Adding my voice to the chorus

Original comment by 0xffff...@gmail.com on 18 Apr 2013 at 9:21

[GoogleCodeExporter]

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

Original comment by judoole on 18 Apr 2013 at 9:26

[GoogleCodeExporter]

I meant to write "they _don't_ seem to".

Original comment by dankirkd@gmail.com on 19 Apr 2013 at 4:38

[GoogleCodeExporter]

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.

Original comment by b.bottema on 31 May 2013 at 4:33

[GoogleCodeExporter]

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

Original comment by b.bottema on 31 May 2013 at 5:19

[GoogleCodeExporter]

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]+')

Original comment by sebastia...@jimdo.com on 2 Jul 2013 at 7:38

[GoogleCodeExporter]

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 <publishers/> 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.

Original comment by b.bottem...@gmail.com on 2 Jul 2013 at 12:34

[GoogleCodeExporter]

We need this too.

Original comment by boiko.i...@gmail.com on 26 Mar 2014 at 1:55

[GoogleCodeExporter]

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

Br,
Jonas

Original comment by jonasb...@gmail.com on 16 Jul 2014 at 1:31