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

No such property: ci for class: groovy.lang.Binding when updating Multibranch plugins

      After updating "Pipeline: Multibranch" (1.11.1 -> 2.0.8) and "Branch API Plugin" (2.9.2 -> 2.14), I get the following error:

      Seen 45 remote branches
      Obtained Jenkinsfile from 3d130723653bda531006ae85801a10eed5fc6249
      [Pipeline] End of Pipeline
      groovy.lang.MissingPropertyException: No such property: ci for class: groovy.lang.Binding
           at groovy.lang.Binding.getVariable(Binding.java:63)
           at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:224)
           at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Checker.java:241)
           at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:238)
           at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:28)
           at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)
           at WorkflowScript.run(WorkflowScript:1)
           at ___cps.transform___(Native Method)
           at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:74)
           at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
           at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
           at sun.reflect.GeneratedMethodAccessor313.invoke(Unknown Source)
           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
           at java.lang.reflect.Method.invoke(Method.java:498)
           at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
           at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
           at com.cloudbees.groovy.cps.Next.step(Next.java:74)
           at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
           at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
           at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
           at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
           at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
           at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
           at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:165)
           at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)
           at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
           at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)
           at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)
           at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
           at java.util.concurrent.FutureTask.run(FutureTask.java:266)
           at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
           at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
           at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
           at java.util.concurrent.FutureTask.run(FutureTask.java:266)
           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
           at java.lang.Thread.run(Thread.java:745)
       Finished: FAILURE

      UPDATE: As suggested by tsbnunes, this is due to the Jenkinsfile being a symlink. A workaround is to simply not use a symlink there.

          [JENKINS-42830] No such property: ci for class: groovy.lang.Binding when updating Multibranch plugins

          Jesse Glick added a comment -

          the real problem is that the multibranch pipelines don't allow us to specify where to get the Jenkinsfile

          Which is already filed separately, with a patch in progress.

          Jesse Glick added a comment - the real problem is that the multibranch pipelines don't allow us to specify where to get the Jenkinsfile Which is already filed separately, with a patch in progress.

          Jonas added a comment -

          Good! Then would there be a way to return a clearer error when a symbolic link is used? Otherwise I guess you can just set this issue to "Won't fix".

          Jonas added a comment - Good! Then would there be a way to return a clearer error when a symbolic link is used? Otherwise I guess you can just set this issue to "Won't fix".

          Jesse Glick added a comment -

          Frankly I have no clue how use of a symlink could possibly lead to the symptoms reported here. Would need to spend time reproducing it to understand.

          Jesse Glick added a comment - Frankly I have no clue how use of a symlink could possibly lead to the symptoms reported here. Would need to spend time reproducing it to understand.

          Mark Waite added a comment - - edited

          Steps I took to duplicate JENKINS-42882 (which I think is the same as this problem):

          1. Copy JDK 8 tar file into my public_html/jdk directory
              $ mkdir -p ~/public_html/jdk/
              $ cp jdk-8u131-linux-*tar.gz ~/public_html/jdk/
            
          2. Copy the jenkins-bugs repo into a local bare repo for faster cloning later
              $ mkdir -p ~/git/bare/bugs/
              $ cd ~/git/bare/bugs/
              $ git clone --mirror https://github.com/MarkEWaite/jenkins-bugs
            
          3. Clone, build, and run the docker instance
              $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-42882
              $ cd JENKINS-42882
              $ git lfs fetch origin origin/lts-with-plugins
              $ git checkout -b lts-with-plugins origin/lts-with-plugins
              $ docker build -t jenkins:JENKINS-42882 .
              $ VOL1=~/public_html:/var/jenkins_home/userContent/
              $ VOL2=~/git/bare:/var/lib/git/mwaite/
              $ docker run -i --rm --publish 8080:8080 --volume $VOL1 --volume $VOL2 jenkins:JENKINS-42882
            
          4. Connect a web browser to that docker instance (http://localhost:8080)
          5. Open the "Bugs - Pipeline Checks" folder
          6. Open the "jenkins-bugs" multi-branch pipeline job
          7. Click the "Scan Multibranch Pipeline" link and then the "Run Now" link to start branch indexing
          8. Confirm the JENKINS-42882 job fails
            
            

          Mark Waite added a comment - - edited Steps I took to duplicate JENKINS-42882 (which I think is the same as this problem): Copy JDK 8 tar file into my public_html/jdk directory $ mkdir -p ~/public_html/jdk/ $ cp jdk-8u131-linux-*tar.gz ~/public_html/jdk/ Copy the jenkins-bugs repo into a local bare repo for faster cloning later $ mkdir -p ~/git/bare/bugs/ $ cd ~/git/bare/bugs/ $ git clone --mirror https: //github.com/MarkEWaite/jenkins-bugs Clone, build, and run the docker instance $ git lfs clone https: //github.com/MarkEWaite/docker-lfs JENKINS-42882 $ cd JENKINS-42882 $ git lfs fetch origin origin/lts-with-plugins $ git checkout -b lts-with-plugins origin/lts-with-plugins $ docker build -t jenkins:JENKINS-42882 . $ VOL1=~/public_html:/ var /jenkins_home/userContent/ $ VOL2=~/git/bare:/ var /lib/git/mwaite/ $ docker run -i --rm --publish 8080:8080 --volume $VOL1 --volume $VOL2 jenkins:JENKINS-42882 Connect a web browser to that docker instance ( http://localhost:8080 ) Open the "Bugs - Pipeline Checks" folder Open the "jenkins-bugs" multi-branch pipeline job Click the "Scan Multibranch Pipeline" link and then the "Run Now" link to start branch indexing Confirm the JENKINS-42882 job fails

          Jesse Glick added a comment -

          If there is a problem loading Jenkinsfile, Jenkins should of course say that. I cannot imagine why it would be reporting the error message displayed here—something is going wrong internally, such as an earlier exception being misreported. Would need to spend time in a debugger. Not currently a priority for me.

          Jesse Glick added a comment - If there is a problem loading Jenkinsfile , Jenkins should of course say that. I cannot imagine why it would be reporting the error message displayed here—something is going wrong internally, such as an earlier exception being misreported. Would need to spend time in a debugger. Not currently a priority for me.

          Sorin Sbarnea added a comment -

          jglick here is a revision that gives a similar confusing error: https://github.com/pycontribs/powertape/commit/81120e0633535f617c2e3e04c329d8ef04e351b1

          I will avoid foce-pushing there in order to allow you to replicate the bug. 

          Sorin Sbarnea added a comment - jglick here is a revision that gives a similar confusing error: https://github.com/pycontribs/powertape/commit/81120e0633535f617c2e3e04c329d8ef04e351b1 I will avoid foce-pushing there in order to allow you to replicate the bug. 

          Jesse Glick added a comment -

          A self-contained, minimal, reproducible test case would be more useful.

          (BTW force-pushing affects refs, and should have no effect on a commit permalink.)

          Jesse Glick added a comment - A self-contained, minimal, reproducible test case would be more useful. (BTW force-pushing affects refs, and should have no effect on a commit permalink.)

          Facing the same issue - the reported error message is misleading and doesn't give a clue about the real root cause. +1

          Constantin Bugneac added a comment - Facing the same issue - the reported error message is misleading and doesn't give a clue about the real root cause. +1

          Had the same error when actually it was just illegal symbol in my sshagent command.

          Mantas Sinkevicius added a comment - Had the same error when actually it was just illegal symbol in my sshagent command.

          Hi,

          I am having this issue too. I have created a (tentative) pull request here https://github.com/jenkinsci/workflow-multibranch-plugin/pull/71 to at least leave the choice of the user to use lightweight checkout or not, that might unblock the people who used this unsupported feature until now and which actually worked.

          On the comment saying that symlinks to Jenkins file are not supported, well I would say this is not the responsibility of Jenkins in general to decide that, but rather each source plugin. The current git plugin doesn't support it, neither the Bitbucket one, however for example for the Bitbucket plugin we "just" need Atlassian to add some new API in their REST API to allow this kind of things. People working in company having support contracts with Atlassian (this is my case) may have the power to ask Atlassian to do that (we haven't contacted Atlassian yet for that, I still don't know at this point if we will).

          Using the above mentionned workaround of specifying a different Jenkinsfile path so that symlink work has two issues:

           - all branches have to follow the same naming convention, while with symlink each branch is free to follow any convention, just symlink "Jenkinsfile" at the root

           - it doesn't work when you symlink the Jenkinsfile to a submodule (it's my case). Again supporting submodules would be the responsibility of each source plugin, like the git one, or the Bitbucket one.

          So please consider the above pull request, that I agree is just a workaround for now, to avoid lightweight checkout in some particular cases, rather than using the big kill switch that would disable it for all builds.

          Cheers,

          Romain

          Romain Geissler added a comment - Hi, I am having this issue too. I have created a (tentative) pull request here https://github.com/jenkinsci/workflow-multibranch-plugin/pull/71  to at least leave the choice of the user to use lightweight checkout or not, that might unblock the people who used this unsupported feature until now and which actually worked. On the comment saying that symlinks to Jenkins file are not supported, well I would say this is not the responsibility of Jenkins in general to decide that, but rather each source plugin. The current git plugin doesn't support it, neither the Bitbucket one, however for example for the Bitbucket plugin we "just" need Atlassian to add some new API in their REST API to allow this kind of things. People working in company having support contracts with Atlassian (this is my case) may have the power to ask Atlassian to do that (we haven't contacted Atlassian yet for that, I still don't know at this point if we will). Using the above mentionned workaround of specifying a different Jenkinsfile path so that symlink work has two issues:  - all branches have to follow the same naming convention, while with symlink each branch is free to follow any convention, just symlink "Jenkinsfile" at the root  - it doesn't work when you symlink the Jenkinsfile to a submodule (it's my case). Again supporting submodules would be the responsibility of each source plugin, like the git one, or the Bitbucket one. So please consider the above pull request, that I agree is just a workaround for now, to avoid lightweight checkout in some particular cases, rather than using the big kill switch that would disable it for all builds. Cheers, Romain

            Unassigned Unassigned
            jones Jonas
            Votes:
            5 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: