|
This looks similar to, but distinct from #34727. Somehow the branch source plugin gets confused about what is the "most recent" commit for a PR, and falls over trying to check out the branch, even if I repeatedly hit the "branch indexing" button.
The confusing thing is that I'm not sure how the checkout is failing. My instance is at http://jenkins.accre.vanderbilt.edu/job/LStore-Branches/branch/PR-85/, but to put the text here, this is the order of events I observed
1) Commit/push 120ff4dbc33db1b410bbbcc681f4fd53c125c1e1 to GH which shows up as 808a15263d77d8166bda573509d58e44a9f1b2b7 in the merge commit
2) Jenkins is notified via webhook, who then performs build #23
3) Commit bb5f59a71d0221d4f3d0f9c61f7733275a2c8e92 to GH
4) Jenkins is notified via webhook, who then performs build #24 with the same commit as before, with a "no changes" message if I drill down into the build. That build bombs with:
hudson.plugins.git.GitException: Could not checkout 808a15263d77d8166bda573509d58e44a9f1b2b7
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:1992)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:152)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at hudson.remoting.Engine$1$1.run(Engine.java:85)
at java.lang.Thread.run(Thread.java:745)
at ......remote call to headnode(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:252)
at hudson.remoting.Channel.call(Channel.java:781)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor589.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
5) Manually reindexing and forcing the build doesn't clean up the state.
It appears that jenkins is trying to use the old merge commit for some reason, but (as of me typing this), if I manually take the commit SHA1 and type it into the web interface, it gives a commit back. Not that it matters, having the results be stale is also not great.
Lemme know if there's more information that I can give.
|
