Repository navigation
GitHubSCMSourceChecksContext failing to load SCMRevisionAction from branch build #271
Description
Take a look at the stack trace in jenkinsci/junit-plugin#308. @cathychan observed something similar from junit on a GitHub branch project build:
org.kohsuke.github.GHIOException: Ran out of retries for URL: https://api.github.com/repos/…/…
at org.kohsuke.github.GitHubClient.sendRequest(GitHubClient.java:407)
at org.kohsuke.github.GitHubClient.sendRequest(GitHubClient.java:355)
at org.kohsuke.github.Requester.fetch(Requester.java:76)
at org.kohsuke.github.GHRepository.read(GHRepository.java:132)
at org.kohsuke.github.GitHub.getRepository(GitHub.java:673)
at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrieve(GitHubSCMSource.java:1685)
at jenkins.scm.api.SCMSource.fetch(SCMSource.java:582)
at io.jenkins.plugins.checks.github.SCMFacade.findRevision(SCMFacade.java:156)
Caused: java.lang.IllegalStateException: Could not fetch revision from repository: … and branch: …
at io.jenkins.plugins.checks.github.SCMFacade.findRevision(SCMFacade.java:159)
at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.resolveHeadSha(GitHubSCMSourceChecksContext.java:131)
at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.<init>(GitHubSCMSourceChecksContext.java:46)
at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.fromRun(GitHubSCMSourceChecksContext.java:24)
at io.jenkins.plugins.checks.github.GitHubChecksPublisherFactory.createPublisher(GitHubChecksPublisherFactory.java:48)
at io.jenkins.plugins.checks.api.ChecksPublisherFactory.lambda$fromRun$0(ChecksPublisherFactory.java:89)
at …
at io.jenkins.plugins.checks.api.ChecksPublisherFactory.fromRun(ChecksPublisherFactory.java:92)
at io.jenkins.plugins.checks.api.ChecksPublisherFactory.fromRun(ChecksPublisherFactory.java:69)
at io.jenkins.plugins.junit.checks.JUnitChecksPublisher.publishChecks(JUnitChecksPublisher.java:41)
at hudson.tasks.junit.JUnitResultArchiver.parseAndSummarize(JUnitResultArchiver.java:310)
at hudson.tasks.junit.pipeline.JUnitResultsStepExecution.run(JUnitResultsStepExecution.java:63)
at hudson.tasks.junit.pipeline.JUnitResultsStepExecution.run(JUnitResultsStepExecution.java:29)
at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at …
Besides the robustness issue covered in the other issue, what is noteworthy here is that GitHubSCMSourceChecksContext.resolveHeadSha(Job) is running, which must make a network operation. That is clearly wrong because this is a branch build for which SCMRevisionAction should exist, so resolveHeadSha(Run) should have been able to get this trivial piece of information from memory. Why then did
Job overload?
Activity
jglick commentedon May 13, 2022
Found it:
fromJobis being used when the build is scheduled.jglick commentedon May 13, 2022
I checked the actions on the
Queue.WaitingItemand it is missingSCMRevisionAction. All it has isCauseActionwithBranchIndexingCause, which has no information.Since looking up the head SHA from
JobScheduledListeneris relatively expensive, and it is not even guaranteed to be correct (a new commit could be pushed before the build starts), it may be best to just skip it. https://github.com/jenkinsci/github-branch-source-plugin/blob/b2f51293cb78fef3005faf129760fecef24c75bc/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubBuildStatusNotification.java#L252 shows that things are not simple.Ideally the multibranch system would be improved so that the new head SHA which was detected during branch indexing will actually be included in the
WaitingItem. Same forBranchEventCause. CurrentlyPullRequestGHEventSubscriber.SCMHeadEventImpldoes not even seem to retain this information.