search

ganesansays / build-pipeline-plugin

Automatically exported from code.google.com/p/build-pipeline-plugin
0 stars 0 forks source link

Add support for manual parameterized builds #54

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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?

Original comment by neale.up...@opencredo.com on 22 Jul 2011 at 8:59

GoogleCodeExporter commented 9 years ago 
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.

Original comment by martineb...@gmx.at on 30 Aug 2011 at 6:04

GoogleCodeExporter commented 9 years ago 
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-change
s-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.

Original comment by filip.noetzel on 30 Aug 2011 at 6:38

GoogleCodeExporter commented 9 years ago 
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.

Original comment by joshua.g...@gmail.com on 30 Aug 2011 at 7:31

GoogleCodeExporter commented 9 years ago 
I think this is similar to issue 53

Original comment by christia...@gmail.com on 31 Aug 2011 at 10:33

GoogleCodeExporter commented 9 years ago 
Issue 53 has been merged into this issue.

Original comment by geo...@centrumsystems.com.au on 27 Nov 2011 at 1:14

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

Original comment by geo...@centrumsystems.com.au on 27 Nov 2011 at 7:43

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

Original comment by geo...@centrumsystems.com.au on 27 Nov 2011 at 7:44

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

Original comment by geo...@centrumsystems.com.au on 27 Nov 2011 at 7:45

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

Original comment by geo...@centrumsystems.com.au on 27 Nov 2011 at 7:55

GoogleCodeExporter commented 9 years ago 
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?

Original comment by markward...@gmail.com on 29 Feb 2012 at 10:45

GoogleCodeExporter commented 9 years ago 
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?

Original comment by fernando...@gmail.com on 29 May 2012 at 8:46

GoogleCodeExporter commented 9 years ago 
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?

Original comment by dankirkd@gmail.com on 8 Jun 2012 at 6:06

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
use this 
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

Original comment by jenkins...@gmail.com on 13 Jun 2012 at 4:23

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dankirkd@gmail.com on 13 Jun 2012 at 5:15

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Yes just discovered this doesn't work with manual execution in a pipeline, very 
annoying. This is a major gap.

Original comment by jenkins...@gmail.com on 13 Jun 2012 at 5:51

GoogleCodeExporter commented 9 years ago 
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-plu
gin.hpi
Patch : 
https://bitbucket.org/jelmerk/build-pipeline-plugin/changeset/5624ec2d686c

Original comment by jkupe...@gmail.com on 30 Jun 2012 at 4:21

GoogleCodeExporter commented 9 years ago 
Setting status to Accepted, as this is clearly a sensible (and even popular) 
feature.

Original comment by er...@ernstdehaan.com on 30 Jun 2012 at 5:57

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dankirkd@gmail.com on 30 Jun 2012 at 6:48

GoogleCodeExporter commented 9 years ago 
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

Original comment by jkupe...@gmail.com on 30 Jun 2012 at 6:58

GoogleCodeExporter commented 9 years ago 
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?

Original comment by dankirkd@gmail.com on 30 Jun 2012 at 7:04

GoogleCodeExporter commented 9 years ago 
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

Original comment by jkupe...@gmail.com on 30 Jun 2012 at 7:08

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dankirkd@gmail.com on 30 Jun 2012 at 7:25

GoogleCodeExporter commented 9 years ago 
please include the patch from jelmerk's fork above!

Original comment by goo...@robig.net on 13 Aug 2012 at 12:19

GoogleCodeExporter commented 9 years ago 
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...

Original comment by geo...@centrumsystems.com.au on 15 Aug 2012 at 5:54

GoogleCodeExporter commented 9 years ago 
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

Original comment by jkupe...@gmail.com on 15 Aug 2012 at 10:08

Attachments:

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

Details coming separately...

Original comment by geo...@centrumsystems.com.au on 17 Aug 2012 at 2:57

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dankirkd@gmail.com on 17 Aug 2012 at 3:05

GoogleCodeExporter commented 9 years ago 
agree with dankirkd, issue 53 is exactly the what i want

Original comment by daiqing2...@gmail.com on 17 Aug 2012 at 6:48

GoogleCodeExporter commented 9 years ago 
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.

Original comment by daiqing2...@gmail.com on 28 Aug 2012 at 11:18

GoogleCodeExporter commented 9 years ago 
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! :(

Original comment by goo...@robig.net on 29 Aug 2012 at 9:54

GoogleCodeExporter commented 9 years ago 
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. ;)

Original comment by goo...@robig.net on 29 Aug 2012 at 11:36

GoogleCodeExporter commented 9 years ago 
Hi - we would really like to have this feature too - is there any progress?

Original comment by el.pablo...@gmail.com on 24 Sep 2012 at 2:06

GoogleCodeExporter commented 9 years ago 
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.

Original comment by tomyka...@gmail.com on 17 Oct 2012 at 8:31

Attachments:

GoogleCodeExporter commented 9 years ago 
My patch in comment 37 is now committed to the repository HEAD.

Original comment by tomyka...@gmail.com on 20 Oct 2012 at 4:42

GoogleCodeExporter commented 9 years ago 
There were any improvement in the implementation of this issue?

Original comment by fernando...@gmail.com on 18 Dec 2012 at 7:21

GoogleCodeExporter commented 9 years ago 
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.

Original comment by bruce.e...@gmail.com on 28 Dec 2012 at 12:24

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

Original comment by hermann....@gmail.com on 8 Jan 2013 at 5:39

GoogleCodeExporter commented 9 years ago 
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\centrumsyst
ems\hudson\plugin\buildpipeline\BuildPipelineView.java:[470,101] inconve
rtible types
[ERROR] found   : hudson.util.RunList<capture#52 of ?>
[ERROR] required: java.util.List<hudson.model.AbstractBuild<?,?>>
[ERROR] 
C:\Downloads\build-pipeline-plugin-a3e3114cb4e1\src\main\java\au\com\centrumsyst
ems\hudson\plugin\util\BuildUtil.java:[60,118] inconvertible types
[ERROR] found   : hudson.util.RunList<capture#812 of ?>
[ERROR] required: java.util.List<hudson.model.AbstractBuild<?,?>>

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

Original comment by igor.rya...@gmail.com on 18 Jan 2013 at 10:01

GoogleCodeExporter commented 9 years ago 
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??

Original comment by Geoff.Bu...@gmail.com on 21 Jan 2013 at 10:17

GoogleCodeExporter commented 9 years ago 
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?

Original comment by igor.rya...@gmail.com on 22 Jan 2013 at 6:53

GoogleCodeExporter commented 9 years ago 
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???

Original comment by geo...@centrumsystems.com.au on 22 Jan 2013 at 11:22

GoogleCodeExporter commented 9 years ago 
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

Original comment by mario.an...@plugtree.com on 5 Feb 2013 at 8:51

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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.

Original comment by dankirkd@gmail.com on 6 Feb 2013 at 3:13

GoogleCodeExporter commented 9 years ago 
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!

Original comment by antolli...@gmail.com on 6 Feb 2013 at 3:03

GoogleCodeExporter commented 9 years ago 
[deleted comment]