Ah, you're correct - I haven't catered for custom variables.  I was assuming that people would just use the ones injected from the environment or parameter tasks.

I had a quick look at using the combobox jelly tag instead of the select option, I don't like how this behaves so will take a little longer to get this working how I would like it - eta a couple of days.

What is the source for the variable that holds the release number? There might be a way I can better support your use case.  For example the plugin now supports a BuildMaster Parameter task that allows you to select a release a build time.

Alternatively you could ignore the environment task altogether and inject your own variables:

1. "BUILDMASTER_APPLICATION_ID" - can contain either the id or application name
2. "BUILDMASTER_RELEASE_NUMBER" - set that to the desired release number

Ignoring this issue, are there any other features you'd like to see in this plugin?

I hadn't realized you had added the job param option. That actually might do the trick. 

That or the env vars as you mentioned would also solve the issue, just didn't occur to me to do that. 

as to other new features, nothing I can currently think of. 

Thanks!

Let me know how it goes. If it’s going to be easier for you I’m happy to get a patch out, otherwise I’ll leave it as is for now.

Updated wiki is at https://plugins.jenkins.io/inedo-buildmaster, this describes the release parameter, changes to variable names, etc.

Using the Env vars as build params is what is going to really work. This will allow me to use only 1 or 2 deployment jobs for all the apps instead of having to use one for each app. 

Not sure if you could make the BM parameter to have two inputs to allow the app and release number to be selected/defined at run time.  You can just define string var params for them but having the app list pre-populated would just help to ensure users put the right values in. But this only applies to being able to have a single Deployment Jobs in Jenkins that would allow you to start a deployment. 

Just to make sure I'm heading down the right track:

You would like the BM Release Parameter to have the option of selecting both the app and release at build time. This should be doable.

Does this solve the "env vars as build params" from the first paragraph, or do you mean you still need the ability to to enter a custom variable into the task config's app & release options instead of just the options I have provided in the list?

Yes, having it allow selecting both. 

The options you listed provide the right method to do it so, no, I don't think there is a need to allow using custom variables in the Create Build or Deploy Build tasks.

Thanks.

Adding reactive parameters turned out to be a LOT harder than I anticipated, so I've taken a different tack and used the [active choices plugin|https://plugins.jenkins.io/uno-choice.] 

I've documented this in the attached word document.  You can either store the groovy code using the [scriptler|https://plugins.jenkins.io/scriptler []|https://plugins.jenkins.io/uno-choice].] plugin, or directly in the job with the active choice plugin.

Select Application and Release.docx

Let me know how this works for you.

I sort of thought doing that might prove difficult. It's solvable in other ways so it really is not a big deal.

I had used that plugin before on an older server but I had to drop it as it ended up causing the server to become corrupted, or rather the scriptler portion. I never used the scriptler portion but it eventually made it so the Jenkins server could not be upgraded. I never had a chance to dig real deep into it.

Then with Scriptler is of course a security issue plugin which here I cannot risk using. 

Anyway, thanks for spending the time to look into it. 

Have a great year!

Good news, I've finally got this working. The solution ended up being rather simple - around 20 lines of code. Shame the Jenkins documentation is garbage, it should have been much easier to get this up and running.  

I've got a bit more testing to do but should have a new release out in the next few days.

Great. I'll keep an eye out for it.  Thanks!

I've released version 3.1 to support this. Let me know how it goes. As a first cut the cascading dropdown was easier to implement as a single parameter with two dropdowns, so let me know how this goes - and whether you need a build number dropdown as well.

I would still like to seperate this out into seperate parameters and get a similar behviour to active choices so depending on time constraints I will continue to play with this.

Put on my test server, works great. Not sure you need to do it any differently but up to you. 

Thank you!

I've got this working with seperate parameters and even support builds as well as application and release. I've got this sitting in a seperate branch and I'm not planning on releasing it for the moment unless anyone asks for it, so if you ever want to move in that direction let me know

actually that would be great. just the other day I was thinking about asking if selecting builds would be possible but it wasn't a critical thing

Just to let you know - I haven't forgotten about this. I am in the process of moving house so I haven't had much spare time lately. This change is ready to go.

However... the BuildMaster 6.2.5 release has a bug in one of the APIs used by the "wait for build to complete" option. There where a couple of other minor changes to the API but those were easily fixed. As soon as I have a fix for this I will be getting a new version out.

No worries. I'm not ready to move to 6.2.x of BM yet anyway. 

thanks for the update. Good luck with the move.