|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
I am trying to provide best steps to reproduce it - but it looks like to be a much more complicated issue.
Slaves are on Ubuntu x64, 14.04. Based on LXC containers. Jenkins version is 1.554.2, git plugin version 2.2.1. Slaves are using Git version 2.0.1. Builds are triggered by post-commit hook from Stash.
Other Git part configuration of the job:
- Other options are:
- prune stale remote-tracking branches
- check out to specific local branch: ${GIT_BRANCH_NAME}
I have a separate job for every directory, so this project has paths XXX and YYY. Current behaviour for a job that tries to build commit that changed only YYY files:
Started by an SCM change
Building remotely on slave05 in workspace /data/jenkins/workspace/Smth
> git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
> git config remote.origin.url ssh://somewhere
Pruning obsolete local branches
Fetching upstream changes from ssh://somewhere
> git --version
> git fetch --tags --progress ssh://somewhere +refs/heads/:refs/remotes/origin/ --prune
[Seen branch in repository origin/...] x many many times
Seen 891 remote branches
Multiple candidate revisions
Scheduling another build to catch up with Smth
Checking out Revision 52941b324c6442ef0389205879e208054311ea62
> git config core.sparsecheckout
> git read-tree -mu HEAD
Command "git read-tree -mu HEAD" returned status code 128:
stdout:
stderr: fatal: Not a valid object name HEAD
> git checkout -f 52941b324c6442ef0389205879e208054311ea62
FATAL: Could not checkout master with start point 52941b324c6442ef0389205879e208054311ea62
hudson.plugins.git.GitException: Could not checkout master with start point 52941b324c6442ef0389205879e208054311ea62
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$8.execute(CliGitAPIImpl.java:1497)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: hudson.plugins.git.GitException: Command "git checkout -f 52941b324c6442ef0389205879e208054311ea62" returned status code 128:
stdout:
stderr: error: Sparse checkout leaves no entry on working directory
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1325)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1301)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1297)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1084)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1094)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$8.execute(CliGitAPIImpl.java:1480)
... 11 more
I don't know why it tries to build this specific commit for now - as it's not the newest one, neither this is the HEAD. I have tried some tests locally - if I try the checkout like that twice in a row the 2nd one will always throw the message about leaving no entry on the directory (first one will work without problems), so maybe there is some redundant checkout call in Jenkins Git plugin? (This whole commit is 2 weeks old, I cannot find an explanation why Jenkins is picking it up, there are many newer ones)