What steps will reproduce the problem? 1. Run a parameterized build.

What is the expected output? What do you see instead? - It would be nice to show parameter names and values for the build. This information is lost in the pipeline view.

What version of the product are you using? On what operating system? - Jenkins 1.446 - Build Pipeline Plugin 1.2.4-ALPHA

Please provide any additional information below. - Perhaps this information could be added to the first (leftmost) "square" of the pipeline, the one that already shows the source control revision number. - Maybe even a tooltip box can be shown with this information when the user hovers the mouse over one of the build steps.

Rough solution in my clone. http://code.google.com/r/mscata-build-pipeline-plugin/source/detail?r=8755a253b136a2de651b17ac99234f4f31662af8

I'm not sure what solution is being suggested, but I don't understand why when a job is triggered via the pipeline view that has build parameters (i.e. "This build is parameterized" is checked and parameters are defined for that job), it doesn't display the "This build requires parameters:" display showing the parameters and their defaults so that they can be changed on the fly as necessary, as it would if you kicked of that same job via a "Build Now". That's all I think that is missing here. The fact this isn't the case is a really big problem I think.

The solution I adopted was to insert a new as the first "square" of the pipeline instance in the view, containing parameter information. If you look at the screenshot, I am using a mock pipeline where I can pass a revision number and a tag name as parameters to the first job. I want to see what parameters were used to start the pipeline, because I can obviously use different parameter values for different pipeline instances. Therefore, I need to have a placeholder somewhere in the pipeline view that tells me which values were used in each instance.

Aside from that, parameters can be set from the pipeline view too. If the first job in the pipeline is parameterized and you hit "Run" from the pipeline view, it will ask for parameter values, and these will be propagated downstream. At least it works for me... ...or maybe you are referring to issue #48? http://code.google.com/p/build-pipeline-plugin/issues/detail?id=48&can=1

I see what you're talking about, and I guess I misunderstood what this issue was addressing then.

My issue has to do with downstream jobs that have their own parameters. The "trigger" buttons circumvent the ability to modify parameters for the job being triggered in the pipeline view. I'll have to find an issue that pertains to that, but I don't think issue #48 is it.

Aha: issue #53 is exactly the issue I was talking about. Looks like that got merged with issue #54.

Commit 388 has removed the parameter details from the project headers. Can you please put them back? We have agreed that they are not needed if the source of truth is always the latest pipeline instance, but that is not always the case, so it is extremely important we have the parameter details in the project headers. They were already removed once before without consultation, and I reinstated them in commit 374. Now they have been removed again. If there is a dispute on this, then please please please make them configurable, but I don't think that just removing them unilaterally is a good approach. Thanks.

I suggest you make that comment in the code revision so it is clear what you want reverted.

Fair point :-)

Good idea to make it configurable. We will have a look at implementing this next time we are making changes.

Or if anyone else wants to take this on, that would be great...

I'll handle this one.