GitHubSCMSourceChecksContext failing to load SCMRevisionAction from branch build

[jglick]

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

github-checks-plugin/src/main/java/io/jenkins/plugins/checks/github/GitHubSCMSourceChecksContext.java

Line 46 in 3baa65d

this.sha = Optional.ofNullable(run).map(this::resolveHeadSha).orElse(resolveHeadSha(job));

fall back to the Job overload?

[jglick]

Found it: fromJob is being used when the build is scheduled.

	at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.<init>(GitHubSCMSourceChecksContext.java:51)
	at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.fromJob(GitHubSCMSourceChecksContext.java:28)
	at io.jenkins.plugins.checks.github.GitHubChecksPublisherFactory.createPublisher(GitHubChecksPublisherFactory.java:55)
	at io.jenkins.plugins.checks.api.ChecksPublisherFactory.lambda$fromJob$1(ChecksPublisherFactory.java:100)
	at …
	at io.jenkins.plugins.checks.api.ChecksPublisherFactory.fromJob(ChecksPublisherFactory.java:103)
	at io.jenkins.plugins.checks.api.ChecksPublisherFactory.fromJob(ChecksPublisherFactory.java:82)
	at io.jenkins.plugins.checks.status.BuildStatusChecksPublisher$JobScheduledListener.lambda$onEnterWaiting$0(BuildStatusChecksPublisher.java:141)
	at …

[jglick]

I checked the actions on the Queue.WaitingItem and it is missing SCMRevisionAction. All it has is CauseAction with BranchIndexingCause, which has no information.

Since looking up the head SHA from JobScheduledListener is 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 for BranchEventCause. Currently PullRequestGHEventSubscriber.SCMHeadEventImpl does not even seem to retain this information.