Builds that are pending while another build is running fail with a No commit found for SHA exception

[larafields]

ERROR: Publisher com.cloudbees.jenkins.GitHubCommitNotifier aborted due to exception
java.io.IOException: {"message":"No commit found for SHA:

We are using GitHub push notifications for pull requests.
When one build is running, and a second PR build to the same branch is triggered, the second PR build will always fail with the above error.
It appears that it is failing because of the following:

1. the sha1 parameter is set at the time of build trigger, not of build start
2. the sha1 parameter is based on /pr/#/merge, not /pr/#/head
3. The job caches the sha that is referenced by /pr/#/merge at the beginning of the build
4. Since build 1 changes the underlying master branch, the /merge on GitHub's side is re-merged based on the result of build 1. This means that that the actual sha from the sha1 parameter from step 1 (which was set when the build was triggered) is now invalid, it no longer exists in GitHub.
5. The build attempts to push the comment about build success to the sha that no longer exists, and it fails which in turn fails the build.

We are a fast-moving team, and often have PRs stack, and this often means a large quantity of spurious failures

A solution to this would be to retrieve the sha of the commit to post the comment to at either the start of the build or at the end (the job pulls and builds the code properly properly, because it is using the refspec for the PR, instead of the sha - the only thing that breaks is the attempt to update the status of the PR)

[larafields]

Clarification, this happens when the attempt is made to set the commit status:
GhprbBuilds.java:133
repo.createCommitStatus(build, state, "Build finished.", c.getPullID(), trigger.getCommitStatusContext(), listener.getLogger());

[larafields]

So, we finally figured out what is causing this, and it technically isn't an error in the GitHub pull request builder, but is something that could be addressed by the plugin. I'm going to close this one and reopen a suggestion for the improvement that will fix this (note, that this specific thing has been bugged off and on by different people, and it is a relatively easy workaround and would likely be a relatively easy improvement.
Link to new issue is here: #269