|
||||||||
|
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 jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I'm reviewing them now.
(and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.
Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.
There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to cause the rate limit to be reached much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that.
Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.4?