I can see your point.

I wrote this assuming that if the latest build doesn't match the latest commit in the branch it is still valuable to know the build status.

So I wrote it assuming that the upstream caller would be responsible for figuring out if this build matched the job.

## Why pass the commit here in the first place then?

In the standard jenkins job there'd be no need to pass in "commit" to this function - it could just return the latest build status and the commit for which it built.

BUT

In my new found pet-love - namely the github PR builder in jenkins - we would get build information a different way. We would need a github CI plugin (which I have already written) which goes off to the given commit and gets the commit status from it. Inside that status is the success/failure etc.

What I could do is change this interface to be only taking ``repo``, ``branch`` and returning ``status``, ``commit``. Then in the github builder we would need to somehow specify that it wants to know about the commit it should be looking for in its configuration...