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

Documentation should clarify distinction between global variable access vs. plain class references

XMLWordPrintable

      Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."

      Here is a very basic example to demonstrate it's not the case:

      // vars/acme.groovy

def setFoo(v) {
    this.foo = v;
}
def getFoo() {
    return this.foo;
}

      // src/com/foo/Zot.groovy

package com.foo

def printAcmeFoo() {
    try {
        echo acme.foo
    } catch (e){
        echo "acme.foo is undefined"
    }
}

      And here is a pipeline:

      import com.foo.Zot

node{
    acme.foo = "5"
    echo acme.foo;
    
    Zot z = new Zot()    
    z.printAcmeFoo()
}

      Actually it shows 2 issues:
      1/ scripts in the vars directory are not singletons
      2/ when accessing undefined field pipeline will hang indefinitely

          [JENKINS-34416] Documentation should clarify distinction between global variable access vs. plain class references

          Martin Vehovsky created issue -
          Martin Vehovsky made changes -
          Description Original: Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."

          Here is a very basic example to demonstrate it's not the case:

          {{ // vars/acme.groovy }}
          {{
          def setFoo(v) {
              this.foo = v;
          }
          def getFoo() {
              return this.foo;
          }
          }}


          {{ // com/foo/Zot.groovy }}
          {{
          package com.foo

          def printAcmeFoo() {
              try {
                  echo acme.foo
              } catch (e){
                  echo "acme.foo is undefined"
              }
          }
          }}

          And here is a pipeline:
          {{
          import com.foo.Zot

          node{
              acme.foo = "5"
              echo acme.foo;
              
              Zot z = new Zot()
              z.printAcmeFoo()
          }
          }}

          Actually it shows 2 issues:
          1/ scripts in the vars directory are not singletons
          2/ when accessing undefined field pipeline will hang indefinitely
          		 New: Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."

          Here is a very basic example to demonstrate it's not the case:


          {code:java}
          // vars/acme.groovy

          def setFoo(v) {
              this.foo = v;
          }
          def getFoo() {
              return this.foo;
          }
          {code}


          {{ // com/foo/Zot.groovy }}
          {{
          package com.foo

          def printAcmeFoo() {
              try {
                  echo acme.foo
              } catch (e){
                  echo "acme.foo is undefined"
              }
          }
          }}

          And here is a pipeline:
          {{
          import com.foo.Zot

          node{
              acme.foo = "5"
              echo acme.foo;
              
              Zot z = new Zot()
              z.printAcmeFoo()
          }
          }}

          Actually it shows 2 issues:
          1/ scripts in the vars directory are not singletons
          2/ when accessing undefined field pipeline will hang indefinitely
          Martin Vehovsky made changes -
          Description Original: Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."

          Here is a very basic example to demonstrate it's not the case:


          {code:java}
          // vars/acme.groovy

          def setFoo(v) {
              this.foo = v;
          }
          def getFoo() {
              return this.foo;
          }
          {code}


          {{ // com/foo/Zot.groovy }}
          {{
          package com.foo

          def printAcmeFoo() {
              try {
                  echo acme.foo
              } catch (e){
                  echo "acme.foo is undefined"
              }
          }
          }}

          And here is a pipeline:
          {{
          import com.foo.Zot

          node{
              acme.foo = "5"
              echo acme.foo;
              
              Zot z = new Zot()
              z.printAcmeFoo()
          }
          }}

          Actually it shows 2 issues:
          1/ scripts in the vars directory are not singletons
          2/ when accessing undefined field pipeline will hang indefinitely           		New: Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."

          Here is a very basic example to demonstrate it's not the case:


          {code:java}
          // vars/acme.groovy

          def setFoo(v) {
              this.foo = v;
          }
          def getFoo() {
              return this.foo;
          }
          {code}

          {code:java}
          // com/foo/Zot.groovy

          package com.foo

          def printAcmeFoo() {
              try {
                  echo acme.foo
              } catch (e){
                  echo "acme.foo is undefined"
              }
          }
          {code}

          And here is a pipeline:
          {code:java}
          import com.foo.Zot

          node{
              acme.foo = "5"
              echo acme.foo;
              
              Zot z = new Zot()
              z.printAcmeFoo()
          }
          {code}

          Actually it shows 2 issues:
          1/ scripts in the vars directory are not singletons
          2/ when accessing undefined field pipeline will hang indefinitely
          Martin Vehovsky made changes -
          Description Original: Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."

          Here is a very basic example to demonstrate it's not the case:


          {code:java}
          // vars/acme.groovy

          def setFoo(v) {
              this.foo = v;
          }
          def getFoo() {
              return this.foo;
          }
          {code}

          {code:java}
          // com/foo/Zot.groovy

          package com.foo

          def printAcmeFoo() {
              try {
                  echo acme.foo
              } catch (e){
                  echo "acme.foo is undefined"
              }
          }
          {code}

          And here is a pipeline:
          {code:java}
          import com.foo.Zot

          node{
              acme.foo = "5"
              echo acme.foo;
              
              Zot z = new Zot()
              z.printAcmeFoo()
          }
          {code}

          Actually it shows 2 issues:
          1/ scripts in the vars directory are not singletons
          2/ when accessing undefined field pipeline will hang indefinitely           		New: Documentation says "Internally, scripts in the vars directory are instantiated as a singleton on-demand, when used first."

          Here is a very basic example to demonstrate it's not the case:


          {code:java}
          // vars/acme.groovy

          def setFoo(v) {
              this.foo = v;
          }
          def getFoo() {
              return this.foo;
          }
          {code}

          {code:java}
          // src/com/foo/Zot.groovy

          package com.foo

          def printAcmeFoo() {
              try {
                  echo acme.foo
              } catch (e){
                  echo "acme.foo is undefined"
              }
          }
          {code}

          And here is a pipeline:
          {code:java}
          import com.foo.Zot

          node{
              acme.foo = "5"
              echo acme.foo;
              
              Zot z = new Zot()
              z.printAcmeFoo()
          }
          {code}

          Actually it shows 2 issues:
          1/ scripts in the vars directory are not singletons
          2/ when accessing undefined field pipeline will hang indefinitely

          Mark added a comment -

          I believe this issue may also be the root cause of JENKINS-36673 as well.

          Mark added a comment - I believe this issue may also be the root cause of JENKINS-36673 as well.
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 170529 ] New: JNJira + In-Review [ 183941 ]
          Andrew Bayer made changes -
          Component/s New: pipeline-general [ 21692 ]
          Andrew Bayer made changes -
          Component/s Original: workflow-plugin [ 18820 ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-36673 [ JENKINS-36673 ]
          Jesse Glick made changes -
          Component/s New: workflow-cps-global-lib-plugin [ 21714 ]
          Component/s Original: pipeline [ 21692 ]

            jglick Jesse Glick
            vehovmar Martin Vehovsky
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: