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