Presumably your Jenkinsfile was trying to use some variable named ci, which was not defined. Without steps to reproduce the problem from scratch it is impossible to help you.

Please reopen when you have steps to reproduce

I just double-checked, and I don't have any "ci" variable. I call `load "ci/path/to/script"` sometimes, though.

Moreover, I get this error when I update the two plugins, and Jenkins works again when I rollback to my previous versions.

In other words, my `Jenkinsfile` works for normal pipelines and for one multibranch pipeline, and only stops working when I update the multibranch plugins, which is why I thought it might be related to them.

I'll try to find a minimal `Jenkinsfile` to reproduce the issue.

Just experienced this same issue, which I found out was actually caused by JENKINS-42882.

As a workaround until that one is fixed, I had to replace the symbolic link to my Jenkinsfile by the actual file contents.

I am indeed using a symbolic link to my Jenkinsfile, too, but it has been working until the update of the plugins I mentioned. I will try without the symlink ASAP, to confirm your observation!

stephenconnolly, tsbnunes: I could finally test Tiago's workaround and I can confirm it works. So something got broken with the plugins I mention w.r.t. having the Jenkinsfile as a symlink.

stephenconnolly: As you requested, I reopened the issue. I see that JENKINS-42882 is in "won't fix". In this case, the real problem is that the multibranch pipelines don't allow us to specify where to get the Jenkinsfile (i.e. the Jenkinsfile has to be at the root of the repository).

I can confirm that is the type of message seen when attempting to use a Jenkinsfile as a symbolic link.

I believe that a Jenkinsfile as a symbolic link creates many difficulties for the optimizations that would like to reduce the number of times a repository is cloned during pipeline work.

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.

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.

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

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.

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. 

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

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