Multi Level Drop Downs

[jdimatteo]

I enhanced extended-choice-parameter-plugin to support multi level drop downs for hierarchical selections. I also added some help files.

For example, with a multi level drop down, you could have two drop downs, first to select a country, and second to select a city. The subsequent drop downs choices depend on the prior selections.

So for example, suppose that there are two country choices: "USA" and "Mexico", and four city choices: "San Francisco", "Chicago", "Cancun", and "Mexico City". First the user selects "USA", then a select "Select a city" drop drop down becomes visible with the options "San Francisco" and "Chicago" (since these two cities are in the USA). If the user goes back and instead chooses "Mexico" for the country, then the city drop down choices will now be "Cancun" and "Mexico" (since these two cities are in Mexico).

I setup a demo at http://173.61.174.142:8080/job/Hierarchical_Dropdown_Demo/build if you'd like to try it out. (Note that you'll need to login to actually run a build, but you don't need to login to just try out the new drop downs.) Note that there is no restriction on the number of levels -- for example see this demo with 4 levels: http://173.61.174.142:8080/job/Bam_Plot/build .

Please note that I had a little trouble documenting the "Text Box" and "Radio Buttons" parameter types. These types don't work in my testing. I documented them as "experimental". Please let me know if you'd like me to elaborate on how these two types fail to work.

Please let me know if you have any suggestions for improvement, and I'll submit a new pull request. Also, please let me know if/how I can be of any assistance in updating the documentation/screenshots at https://wiki.jenkins-ci.org/display/JENKINS/Extended+Choice+Parameter+plugin .

[buildhive]

Jenkins » extended-choice-parameter-plugin #27 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[jenkinsadmin]

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

[imod]

Nice addition, but when I look at the parameters used in a build:
http://173.61.174.142:8080/job/Bam_Plot/11/parameters/?
Then the format/presentation looks quite strange for the "selection" parameter.
I did not really try it, but I'm not so sure how this coma separated values will make my life easier... specially when having multiple selections in one parameter.
Can you elaborate on how you are using these?
I think the nice thing here is more to make it easier for a user to locate the correct value then actually having the whole dropdown path in the value itself. So I think the UI is cool, but the actual value is not "very handy".

[buildhive]

Jenkins » extended-choice-parameter-plugin #28 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[jdimatteo]

@imod, good points about the parameter value format.

With the last commit, now only the last drop down selection is used for the parameter value(s). So "Multi-Level Single Select" parameter values no longer need a delimiter (since there is just one value), and multiple selections with "Multi-Level Multi Select" parameters are separated by the delimiter.

FYI, I agree that the old format with the whole drop down path in the value was not "very handy". (The Bam_Plot job which actually uses this multi-level multi select parameter actually just passes the "selection" values to a script, which just got rid of all but the last drop-down selections anyway, so I think it makes sense to just leave off the full path in the plugin itself like you suggested.)

For example, http://173.61.174.142:8080/job/Bam_Plot/6/parameters/? is the old parameter value format for two selections (with the full paths), and http://173.61.174.142:8080/job/Bam_Plot/12/parameters/? is the new value format for the same two selections.

[jdimatteo]

@vimil, regarding the use of tab delimited files for the Multi-Level data files, instead of the property file format that the rest of the plugin uses:

I need to support drop downs populated with choices from a tab delimited file, because I'm working with a small lab and that is the format that they are maintaining the data in. I realize that this doesn't fit in very nicely with the rest of the plugin design and usage. However, I can't change the format of the data file (there is someone updating it every few days, and a simple tab delimited file is easier for them to work with in a spreadsheet application).

Please consider accepting the use of a tab delimited file for the "Multi-Level" parameter types, while the other types continue to use a proper property file format.

Perhaps down the line we can work on supporting both file formats and/or allow a script to be run before the drop downs are populated so that one could easily transform an arbitrary file format into the property file format.

[buildhive]

Jenkins » extended-choice-parameter-plugin #29 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[vimil]

merging pull request, todo: enhance to also support property file format for multi-level dropdown parameters

[oleg-nenashev]

@vimil
What about the new release of the plugin?
This functionality seems to be very useful.

[jdimatteo]

Please let me know if I can be of any assistance updating any documentation or anything else to help get a new release of the plugin.

[githublurker]

@jdimatteo How do I get ALL the parameter values (NOT just the last one) if I do Multi-Level Single Select ?

[oleg-nenashev]

I suppose that the plugin's Wiki page should be updated.
The current description seems to be very outdated + all features are described in the changes history

[jdimatteo]

@githublurker Currently only the most drilled down value of each selection is available. For example, if you had a multi-level select of country and city, and you chose "USA" and "Chicago" as the first selection and then "Mexico" and "Cancun" as the second selection, then only "Chicago" and "Cancun" values are available (not "USA" and "Mexico").

It wouldn't be hard to supply the prior values, it is just a question of a reasonable format and whether it is ever helpful or not. Do you mind explaining your use case so that it is clear an example where the prior values are helpful?

Do you have any suggestions for a format? The original pull request actually DID contain the prior values, in a format such as this for the country/city example (if I recall properly):

USA,Chicago,,Mexico,Cancun

Perhaps I can add a check box of whether or not prior selections are included. By default only the last values will be included, but if enabled then all the selections will be included with a single separator between the parts of a single selection and two separators (e.g. ",,") separating different selections. Does this sound reasonable?

I don't remember the details, but I had tried using new lines between selections (instead of two separators) but StringParameterValue didn't support newlines as I recall.

githublurker if you could give an example use case to validate that this is actually useful and comment on a format, I'd appreciate it.

[m1ndful]

@jdimatteo One of use cases that are pretty useful.
We have one redeploy job for snapshots and releases for all environments and for all branches. For example we have certain repositories with snapshots/releases:
-custom build
-develop snapshots build
-master_release build
-master_snapshots build
I have made script which pulls from nexus versions depends on repository and make one single file with two dimension choice. First you pick build, then you pick version.
Now I have issue. In order to trigger deploy job I need not only snapshot version, but also to specify repository where snapshot/release is located :( At this point if you add all parameters, I'll be able to do this.
For example we are using "Build flow plugin" which allows through Groovy/DSL get all jenkins parameters/variables and pass them to other jobs.

In my Test job:
"Define build flow using flow DSL" :

out.println 'Triggered Parameters Map:'
out.println params
out.println 'Build Object Properties:'
build.properties.each { out.println "$it.key -> $it.value" }

I got output:

Triggered Parameters Map:
[SNAPSHOT:0.26.106]
Build Object Properties:
moduleRoot -> /app/jenkins/workspace/test_for_versions_bf
rootDir -> /var/lib/jenkins/jobs/test_for_versions_bf/builds/2014-02-26_22-44-14
artifactManager -> jenkins.model.StandardArtifactManager@38a294a1
IDFormatter -> java.text.SimpleDateFormat@b61f11ff
time -> Wed Feb 26 22:44:14 FET 2014
...

As you can see I have SNAPSHOT version, but no way to specify repository where this snapshot located...

Also from my point, it will be very nice to be able to set "separator", so it will be easier to parse parameters.

Feel free for any questions.

Thanks.

[jdimatteo]

@m1ndful thanks for explaining a use case.

I'll try and update this sometime in the next couple weeks. I'd also like to update the wiki with some screenshots. Maybe if I take the time to add the option for including prior selection, someone else can take the time to update the wiki with some useful screenshots and descriptions?

[sykrim]

@jdimatteo Another use case for the multi-level single select feature that githublurker suggested would be in the case when I need to pull different git tags/revisions based on a some user selections. Consider the simplest case, in which one would only need to use 2 git repo's. User selects the revision on the first git which in this particular case we are discussing influences the revision of the second git repo. So currently, using your choice parameter, we get the revision of the second git repo, but there is no way using the same extended choice parameter to get the revision of the first git repo that the user selected.