[JENKINS-11851] More options for default parameters

[timja]

See description I put together a while ago on the wiki. I will also attach the code I wrote that works, but never got committed.

https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options

---

Originally reported by jacob_robertson, imported from: More options for default parameters

• status: Reopened
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

jacob_robertson:

Shows the changes needed to the core, plus an example of how the String parameter might work.

[timja]

haunted:

Hi, will this issue be fixed ? or can someone tell me a workaround/plugin for default values for parameter ?

[timja]

danielbeck:

Please submit suggested code changes as pull requests on GitHub.

[timja]

ntshako:

I am searching for years now for such a feature! As I see it, this would improve the usability of parameterized builds a lot, because you save much time of users who don't need to change and even don't need to know about any of the parameters.

I cannot imagine that an option to hide predefined parameters would be so much effort to implement...

[timja]

danielbeck:

Plugins like env-inject allow you to centrally define variables for reuse in a job configuration, so this is not needed.

[timja]

jacob_robertson:

No. Centrally managed information is exactly the opposite of what this feature is requesting. For two-people shops sure, whatever. But for 300-people shops with thousands of jobs surely you can see the financial cost for these types of things to be maintained centrally - better to have them maintained by the individual teams. Naturally, there are different ways to fix this, but I am not aware of any Jenkins plugin that actually satisfies the given use case. I do wonder if going through CloudBees would be helpful. (We have a support license.)

[timja]

danielbeck:

To clarify, those are configured in individual job configurations (there are global and per-node options as well, but I referred to the job-specific ones). I meant centrally as in "you don't need to copy the same option over and over in a single job's config". See here:
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin#EnvInjectPlugin-Atjoblevel

[timja]

ntshako:

as I see it the the implementation described here: https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options?focusedCommentId=80183932&#comment-80183932
would be much easier regarding usability than the workaround with the EnvInject Plugin, that has other intentions than just "hide" properties being setup individually for single jobs from the gui.

So I really don't know why you won't let the users decide what and which plugin he prefers to cover this use case?

[timja]

danielbeck:

So I really don't know why you won't let the users decide what and which plugin he prefers to cover this use case?

This is a change requested for Jenkins core, not about a new plugin. The trend has long been to move functionality out of core into independently updatable plugins, so rejecting new feature requests that are very similar to established plugins' features is consistent with that.

Of course I'm not the final arbiter on what goes in and what does not, so feel free to reopen this issue. But based on my experience, this will not make it in, as it is not actually a necessary feature (since it has adequate alternatives), and brings significant additional complexity with it.

[timja]

ntshako:

I have tried out the workaround with the EnvInjectPlugin and generally it works.
(by just declaring the key/value paris in the "Properties Content" section, like shown here: )
https://wiki.jenkins-ci.org/download/attachments/57999800/EnvInject_Path.png?version=1&modificationDate=1342694716000

But I still have a big disadvantage using this workaround. Finally I am also using the Promoted Builds Plugin and unfortunately the build parameters, predefined with the EnvInjectPlugin, won't be read by the Job Promotion being executed.

Sure I have the possibility to configure the EnvInjectPlugin with my needed properties also for every single promotion step, but after all I need to duplicate the property definitions here again and again... and thats exactly what I wanted to prevent by using the EnvInjectPlugin!
Whereas the properties, defined with the Jenkins Core functionality, are indeed readable by the configured promotion executions out-of-the-box.

Or do you know any workaround for this use case as well?

[timja]

danielbeck:

Or do you know any workaround for this use case as well?

No. IMO, Promoted Builds is beyond broken, so I haven't used it in years.

Also IMO, not a reason to reject env-inject for the original use case. Because I'm fairly sure it makes no difference in most use cases. This could easily be changed to an enhancement request for Promoted Builds without needing to change completely how parameters work.

[timja]

ntshako:

Also IMO, not a reason to reject env-inject for the original use case. Because I'm fairly sure it makes no difference in most use cases. This could easily be changed to an enhancement request for Promoted Builds without needing to change completely how parameters work.

If depends on how many people use and need it for the promoted builds plugin steps as well. And I can imagine that those are quite a lot! For all those people the "workaround" with the EnvInjectPlugin is just an enormous effort to configure this plugin for every promotion step, and makes it simply unusable.
I think the proposal on this site https://wiki.jenkins-ci.org/display/JENKINS/Parameter+Defaults+Options doesn't sound like a completely changed behavior of the parameter feature in Jenkins... so I'm really a bit confused, why there is no one releasing this one

[timja]

jbreda:

Hello,

I really need this feature ! I can't get anything work with EnvInject for my case. 10 years after, could we get this feature so many people are asking for ?

My case : I have two jobs :

• one free-style job (let's call it 'firstJob') which invokes a maven target and specifies a custom property from an environment variable (example : mvn clean -Dcustom=${MY_AWESOME_ENV_VAR}). This environment variable is used to specify technical setup (such a host) which should only be managed by an administrator.
• another pipeline job, calling the first job (via the 'build' target), which needs to override this property (to adapt the target host), and so, which needs to override this environment variable.

EnvInject wasn't able to override anything. I tried "withEnv" right before calling "build firstJob" in my pipeline job but it didn't work. I also tried to use the EnvInject plugin in firstJob to override the value but it doesn't work too.

I tried using parameters but if a user launch a build on my first job, he's prompted to select a value, which is purely technical and which he doesn't have to care about.

Using EnvInject to override parameters doesn't work too since whatever I do, parameters input is always prompted to the user.

 

Having parameters which really handle default values, never prompted as suggested, is the best way in my opinion. Environment variable are not suitable since we never know if an override will be taken into account (depending invoked tool) and since it relies on an environment. When launching two tasks in parallel on the same environment there could be some problems. Parameters are the way to parameter a build.

 

How can I achieve this without this feature ? For now I'm blocked, spending hours on internet to find a tricky solution.