Thanks for the clear steps to reproduce the issue. I've created a 42882 branch in my jenkins-bugs repository which shows the problem. That branch is evaluated in my docker-lfs configuration. Patches are welcomed to fix the bug...

+1 to this issue, just hit it myself. 

For reference, when Jenkinsfile is symlinked to ci/build.groovy, this is what I'm seeing:

Obtained Jenkinsfile from f5035722844a5de1222dfaba340171ca060f3c6b
[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.GeneratedMethodAccessor332.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
 

omervk I have exactly the same trace except it can't find the property build as the link starts with build.

If this behavior isn't intentional and it worked before with older versions it's definitely a regression because it might cause projects to fail (and the problem isn't obvious from the error messages and hard to track).

I have no indication that this ever worked with any version of the git plugin.

I also started experiencing this issue after upgrading to v2 of the plugin. It worked fine with v1.

As a workaround for the time being I replaced the symlink by the actual Jenkinsfile contents. For reference, before finding this issue, I came across this one - JENKINS-42830.

tsbnunes can you describe in more detail what you mean by "v2 of the plugin" and "it worked fine with v1"? I'm not aware of any version of the GitSCMContent API that supported Jenkinsfile as a symbolic link to another location.

Hi markewaite. Sorry, I believe my previous comment was not clear and completely accurate.

I just updated a bunch of Jenkins plugins, mostly related to the Pipeline (workflow) and SCM API.

A fair amount of them had dependencies among each other and had warnings referring to this [post|https://jenkins.io/blog/2017/01/17/scm-api-2/,] which mentions the differences of the new SCM API 2, so this issue might actually be caused by a different component and not git-plugin.

Some of the relevant upgrades I did were:

• branch-api: 1.11.1 -> 2.0.8
• scm-api: 1.3 -> 2.1.1
• git: 3.0.1 -> 3.2.0
• workflow-multibranch: 2.9.2 -> 2.14

I have single-branch pipeline jobs with symlinks to Jenkinsfiles that continue working fine, so this seems to only affect multi-branch pipeline jobs.

In the end, it might not be caused by git-plugin itself, but by a regression introduced by one of the others?

I'm afraid I don't know enough about Jenkins plugins internals to easily identify the culprit here.