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

Groovy truth issue in Pipeline script

    Details

    • Similar Issues:

      Description

      A Jenkins pipeline script combining two String values with a logical AND (&& operator) does not behave as expected:

      '' && '' -> false
      'a' && 'b' -> 'b'
      'a' != '' && 'b != '' -> true
      

      So when combining two non empty values the result is not of type boolean but the second value of type String.

      The following script demonstrates this behavior:

      node {
          def doit = { String s1, String s2 ->
              def p = { v -> "'$v' (${v.class})" }
          
              echo "s1 = ${p s1}, s2 = ${p s2}"
              echo "s1 && s2 = ${p s1 && s2}"
              echo "s1 != '' && s2 != '' = ${p s1 != '' && s2 != ''}"
          }
       
          doit '', ''
          doit 'foo', 'bar'
      }
      

      Console of an example run in my environment:

        Attachments

          Activity

          m_olk Marcus Olk created issue -
          m_olk Marcus Olk made changes -
          Field Original Value New Value
          Summary Groovy truth issue in parameterized Pipeline script Groovy truth issue in Pipeline script
          m_olk Marcus Olk made changes -
          Description A Jenkins pipeline script combining two {{String}} values with a logical AND ({{&&}} operator) does not behave as expected:

          {code}
          '' && '' -> false
          'a' && 'b' -> 'b'
          'a' != '' && 'b != ''' -> true
          {code}

          So when combining two non empty values the result is not of type {{boolean}} but the second value of type {{String}}.

          The following script demonstrates this behavior:

          {code}
          node {
              def doit = { String s1, String s2 ->
                  def p = { v -> "'$v' (${v.class})" }
              
                  echo "s1 = ${p s1}, s2 = ${p s2}"
                  echo "s1 && s2 = ${p s1 && s2}"
                  echo "s1 != '' && s2 != '' = ${p s1 != '' && s2 != ''}"
              }
           
              doit '', ''
              doit 'foo', 'bar'
          }
          {code}

          Console of an example run in my environment:
           !Screen Shot 2016-11-30 at 22.58.37.png!
          A Jenkins pipeline script combining two {{String}} values with a logical AND ({{&&}} operator) does not behave as expected:

          {code}
          '' && '' -> false
          'a' && 'b' -> 'b'
          'a' != '' && 'b != '' -> true
          {code}

          So when combining two non empty values the result is not of type {{boolean}} but the second value of type {{String}}.

          The following script demonstrates this behavior:

          {code}
          node {
              def doit = { String s1, String s2 ->
                  def p = { v -> "'$v' (${v.class})" }
              
                  echo "s1 = ${p s1}, s2 = ${p s2}"
                  echo "s1 && s2 = ${p s1 && s2}"
                  echo "s1 != '' && s2 != '' = ${p s1 != '' && s2 != ''}"
              }
           
              doit '', ''
              doit 'foo', 'bar'
          }
          {code}

          Console of an example run in my environment:
           !Screen Shot 2016-11-30 at 22.58.37.png!
          abayer Andrew Bayer made changes -
          Component/s workflow-cps-plugin [ 21713 ]
          Component/s pipeline [ 21692 ]
          Hide
          reinholdfuereder Reinhold Füreder added a comment - - edited

          Presumably the same problem (groovy cps behaving differently for object references with respect to type coercion and groovy truth) causes this:

          #!/usr/bin/env groovy
          
          stage('stage') {
            echo "f1(): ${f1()}"
            echo "f2(): ${f2()}"
            echo "f3(): ${f3()}"
            echo "f4(): ${f4()}"
          }
          
          def f1() {
              return null
          }
          
          boolean f2() {
              return null
          }
          
          def f3() {
              return false
          }
          
          boolean f4() {
              return false
          }
          

          => actual log output:

          [Pipeline] stage
          [Pipeline] { (stage)
          [Pipeline] echo
          f1(): null
          [Pipeline] echo
          f2(): null
          [Pipeline] echo
          f3(): false
          [Pipeline] echo
          f4(): false
          [Pipeline] }
          [Pipeline] // stage
          [Pipeline] End of Pipeline
          

          or in short:

          f1(): null
          f2(): null
          f3(): false
          f4(): false
          

          Expected:

          f1(): null
          f2(): false // !
          f3(): false
          f4(): false
          

          Note: Using the greatest and latest versions, i.e. Jenkins (Core) v2.130, "Pipeline: Groovy"/workflow-cps plugin v2.54

          Show
          reinholdfuereder Reinhold Füreder added a comment - - edited Presumably the same problem (groovy cps behaving differently for object references with respect to type coercion and groovy truth) causes this: #!/usr/bin/env groovy stage( 'stage' ) { echo "f1(): ${f1()}" echo "f2(): ${f2()}" echo "f3(): ${f3()}" echo "f4(): ${f4()}" } def f1() { return null } boolean f2() { return null } def f3() { return false } boolean f4() { return false } => actual log output: [Pipeline] stage [Pipeline] { (stage) [Pipeline] echo f1(): null [Pipeline] echo f2(): null [Pipeline] echo f3(): false [Pipeline] echo f4(): false [Pipeline] } [Pipeline] // stage [Pipeline] End of Pipeline or in short: f1(): null f2(): null f3(): false f4(): false Expected: f1(): null f2(): false // ! f3(): false f4(): false Note: Using the greatest and latest versions, i.e. Jenkins (Core) v2.130, "Pipeline: Groovy"/workflow-cps plugin v2.54
          abayer Andrew Bayer made changes -
          Labels pipeline complex-cps-code pipeline triaged-2018-11

            People

            • Assignee:
              Unassigned
              Reporter:
              m_olk Marcus Olk
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: