Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26897

Specify true/false values for boolean parameter

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      We need to parameterize our builds so that the user can specify whether to refresh-dependencies or not, which in gradle-parlor translates to the optional "--refresh-dependencies" parameters.

      It would be really nice if you could specify true/false values for a boolean parameter. We would then create a parameter with true-value set to "--refresh-dependencies" and false-value set to "", and then just use $gradleRefreshDependencies when invoking the gradle script.

      Our current workaround is to create a text parameter with the description "Please add --refresh-dependencies" to refresh dependencies. This is simple enough, of course, but the use case is ideal for boolean parameters.

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          This should probably be handled in a 'wrapper' build script translating Jenkins parameters into what the build script expects (can be the sh/batch command). Even if Jenkins support is needed for some reason, this should be a plugin.

          Show
          danielbeck Daniel Beck added a comment - This should probably be handled in a 'wrapper' build script translating Jenkins parameters into what the build script expects (can be the sh/batch command). Even if Jenkins support is needed for some reason, this should be a plugin.
          Hide
          elygre elygre added a comment -

          In our use case, there is no external build script. Instead, everything is handled by the "Invoke Gradle Script" build step.

          First, the parameters section specifies two input parameters: "version" and "refreshDependencies". They are both string parameter, even though the use case calls for the second one to be boolean (refresh or not).

          Second in the "Invoke Gradle Script" build step, there is an input box named "switches". In this box we currently put "Pversion=$version $refreshDependencies". There is no external script before, and since the parameter "-refresh-dependencies" is parsed by gradle before the script itself starts, we have no way of translating the value ourselves.

          In short:

          1) As far as I can tell, it is today not possible to use a boolean parameter to decide whether to pass a switch or not to the built-in gradle support, even though that is the perfect use case for a boolean parameter.
          2) The workaround is simple, but kinda removes the motivation for a boolean parameter. After all, everybody could use a string parameter and tell users to enter "true" or "false" themselves

          Therefore, I respectfully disagree. Jenkins should have a built-in mechanism for translating a boolean parameter to the string value required later on, if you need something else than "true" and "false".

          Show
          elygre elygre added a comment - In our use case, there is no external build script. Instead, everything is handled by the "Invoke Gradle Script" build step. First, the parameters section specifies two input parameters: "version" and "refreshDependencies". They are both string parameter, even though the use case calls for the second one to be boolean (refresh or not). Second in the "Invoke Gradle Script" build step, there is an input box named "switches". In this box we currently put " Pversion=$version $refreshDependencies". There is no external script before, and since the parameter " -refresh-dependencies" is parsed by gradle before the script itself starts, we have no way of translating the value ourselves. In short: 1) As far as I can tell, it is today not possible to use a boolean parameter to decide whether to pass a switch or not to the built-in gradle support, even though that is the perfect use case for a boolean parameter. 2) The workaround is simple, but kinda removes the motivation for a boolean parameter. After all, everybody could use a string parameter and tell users to enter "true" or "false" themselves Therefore, I respectfully disagree. Jenkins should have a built-in mechanism for translating a boolean parameter to the string value required later on, if you need something else than "true" and "false".
          Hide
          danielbeck Daniel Beck added a comment -

          Jenkins should have

          The problem is that this actually is a rather specialized use case not a lot of users will face. (And the few interested in this will have a slightly different problem, like wanting to translate the numbers 1-6 to percentages 16, 33, 50, 67, 83, 100).) Adding support for it in core will result in additional clutter for almost everyone while helping very few. There's numerous parameter-related plugins already that can probably do this for you, not to mention env-inject rewriting build parameters in a script.

          Me saying "This should be done in a plugin" does not mean "This should not be done at all". It just means it makes no sense to add it to Jenkins core.

          Show
          danielbeck Daniel Beck added a comment - Jenkins should have The problem is that this actually is a rather specialized use case not a lot of users will face. (And the few interested in this will have a slightly different problem, like wanting to translate the numbers 1-6 to percentages 16, 33, 50, 67, 83, 100).) Adding support for it in core will result in additional clutter for almost everyone while helping very few. There's numerous parameter-related plugins already that can probably do this for you, not to mention env-inject rewriting build parameters in a script. Me saying "This should be done in a plugin" does not mean "This should not be done at all". It just means it makes no sense to add it to Jenkins core.

            People

            • Assignee:
              Unassigned
              Reporter:
              elygre elygre
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: