|
||||||||
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
@ikedam, downstream job A uses parameter values as-is, i.e. unexpected values e, f, g are used in processing exactly as expected values a, b, c does. In my case parameter types are just a facade for user-friendly UI, but as build execution is started the values are just strings (like environment variables).
And answering to your questions:
In same way as values a, b, c. One of my real example for parameter meaning is a set of host names where SSH session will connect to.
Yes.
Not using will require additional checks and custom code in build steps. No, I did not skip unexpected values.
It will fail the build of job A. Behavior you suggest is in same sense harmful and not backward compatible as one implemented in version 2.23.