• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • workflow-cps-plugin
    • None

      Consider the following workflow script:

      echo "bool=$bool"
      echo bool.getClass().toString()

      Output:

      Started by user Jos Backus
      Running: Print Message
      bool=false
      Running: Print Message
      class java.lang.String
      Running: End of Workflow
      Finished: SUCCESS

      I would expect the name of the class to be java.lang.Boolean, not java.lang.String. This forces one to add lines such as:

      bool = bool == 'true'

          [JENKINS-27295] Boolean parameters injected as String

          Jos Backus created issue -

          Baptiste Mathus added a comment - Linking to the associated thread can help: https://groups.google.com/forum/#!topic/jenkinsci-users/dO2LRFNRQ4Q
          Jesse Glick made changes -
          Link New: This issue is duplicated by JENKINS-27388 [ JENKINS-27388 ]

          Jesse Glick added a comment -

          By design; parameter values traditionally have been injected as environment variables, so Workflow just followed suit.

          Now when using parameter value implementations defined in core, or in a plugin depending on core 1.568+, the new getValue method could be called. For compatibility reasons, we cannot change the type of the existing variables, but we could introduce new variables (or a map variable parameters, etc.) based on the rich types.

          Unfortunately there is no clear way to distinguish whether a given ParameterValue implementation is specifying getValue. The Javadoc says it can return this as a fallback, yet the default implementation is null, which may be a legitimate return value in an override. Perhaps we need to just use Util.isOverridden, which is undesirable since it would give incorrect results if there are any proxying implementations, though probably there are not.

          Jesse Glick added a comment - By design; parameter values traditionally have been injected as environment variables, so Workflow just followed suit. Now when using parameter value implementations defined in core, or in a plugin depending on core 1.568+, the new getValue method could be called. For compatibility reasons, we cannot change the type of the existing variables, but we could introduce new variables (or a map variable parameters , etc.) based on the rich types. Unfortunately there is no clear way to distinguish whether a given ParameterValue implementation is specifying getValue . The Javadoc says it can return this as a fallback, yet the default implementation is null , which may be a legitimate return value in an override. Perhaps we need to just use Util.isOverridden , which is undesirable since it would give incorrect results if there are any proxying implementations, though probably there are not.
          Jesse Glick made changes -
          Issue Type Original: Bug [ 1 ] New: Improvement [ 4 ]
          Summary Original: Boolean parameters injected as Strings into Groovy Workflow Plugin environment New: Boolean parameters injected as String
          Jesse Glick made changes -
          Link New: This issue is blocking JENKINS-27413 [ JENKINS-27413 ]

          Jesse Glick added a comment -

          Current implementation here.

          Jesse Glick added a comment - Current implementation here .
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-29952 [ JENKINS-29952 ]
          Jesse Glick made changes -
          Link New: This issue is related to SECURITY-170 [ SECURITY-170 ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-30222 [ JENKINS-30222 ]

            jglick Jesse Glick
            josb Jos Backus
            Votes:
            1 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: