I am writing a Jenkins pipeline. It checks out from repo A first and should later on build and test the code. But for this, I need a certain directory from a different repository (repo B). So I have a first pipeline step checkout([$class: 'GitSCM'] and so on) that clones from repo A and then a second one that clones from repo B. Because I only need the current version of that particular directory of repo B, I thought a combination shallow clone and sparse checkout is the way to go for me.
In my Jenkins file I have the following options for checking out from repo B:
extensions: [[$class: 'CleanBeforeCheckout'], [$class: 'CloneOption', shallow: true], [$class: 'SparseCheckoutPaths', sparseCheckoutPaths: [[ path: '<directory>/*']]]
The job runs fine without the sparse checkout option.
Using this option, I get two confusing error messages, both with the same number:
Command "git read-tree -mu HEAD" returned status code 128:
stdout:
stderr: error: Sparse checkout leaves no entry on working directory
hudson.plugins.git.GitException: Command "git checkout -f 89ab1797242776520bc708122bbf948ab8887c16" returned status code 128:
stdout:
stderr: error: Entry 'Jenkinsfile' not uptodate. Cannot update sparse checkout.
What is the problem? Which error is "correct"? Something not uptodate? Can sparse checkout not check out the latest version, even if it is like 100 years old?
UPDATE 1: I just tried the following: Added new job to Jenkins based on the failing one. Ran it. I thought if this is an error due to earlier checkouts, it should not occur in a clean workspace. But it failed with the same error messages.
UPDATE: By changing file names I verified that the file that is not supposed to be up to date is indeed the file containing my running pipeline. So it seems to me that this file gets changed after having been checked out by Jenkins. This would then stop Jenkins git from checking out more because you can only pull into a clean workspace.
If this is the case, what could cause the phantom update? I am using Windows, so I just blamed it on the annoying \r\n problem. But I forced my local git to commit \n line endings (by setting core.autocrlf to input), changed the line endings in that file, committed it and ran the job. Result is still the same.