github-checks-plugin `GitHubSCMSourceChecksContext` failing to load `SCMRevisionAction` from branch build

Take a look at the stack trace in https://github.com/jenkinsci/junit-plugin/issues/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 https://github.com/jenkinsci/github-checks-plugin/blob/3baa65d7486f6298215fbda14cb1b23f752fe73a/src/main/java/io/jenkins/plugins/checks/github/GitHubSCMSourceChecksContext.java#L46 fall back to the Job overload?

May 13 '22 21:05 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 …

May 13 '22 22:05 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.

May 13 '22 22:05 jglick