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

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

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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 Tiago Nunes, this is due to the Jenkinsfile being a symlink. A workaround is to simply not use a symlink there.

        Attachments

          Issue Links

            Activity

            Hide
            ssbarnea Sorin Sbarnea added a comment -

            Jesse Glick 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. 

            Show
            ssbarnea Sorin Sbarnea added a comment - Jesse Glick 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. 
            Hide
            jglick 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.)

            Show
            jglick 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.)
            Hide
            cb_tes_global 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

            Show
            cb_tes_global 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
            Hide
            mantasink Mantas Sinkevicius added a comment -

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

            Show
            mantasink Mantas Sinkevicius added a comment - Had the same error when actually it was just illegal symbol in my sshagent command.
            Hide
            romaingeissler 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

            Show
            romaingeissler 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

              People

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

                Dates

                • Created:
                  Updated: