I'm trying to build the git hash / branch that just got pushed. GitHub passes the correct webhook, and https://JENKINSURLHERE/log/webhooks/?auto_refresh=true shows me the correct data, but the build notes "After filtering out what's already been built: []\nNothing seems worth building, so falling back to the previously built revision:" then lists the git hash of the previous build.

Most of the time the new code is the most recent code, but not always. Consider the case where different branch names yield different build steps – e.g. git-flow deploys release/* branches to the test server and dev to the dev server. In this case, I want to push a new branch name on a previously built git hash, and have it build again with different results.

Here's steps to reproduce the problem:

1. Given a repository on GitHub or GitHub Enterprise with some history (2 or 3 commits is enough)
2. Given a build that listens to GitHub (or GitHub Enterprise) via webhook
3. Given that the build has run a few times already
4. Create a new branch on an old commit (not a tip), for example "initial commit"
5. Push the new branch
6. Note that the github webhook log shows the specified git hash and branch
7. Note that it builds the tip, not the specified commit

Failure cause:
GitHub plugin only gets the repository url and committer name from the webhook data (see https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/com/cloudbees/jenkins/GitHubWebHook.java#L175), it does not get the other details.

Proposed solution:
GitHub plugin creates parameters of relevant webhook data that other plugins / parameterized builds could leverage such as GIT_HASH, GIT_BRANCH, etc, etc. Plugins such as http://www.sourceprojects.org/jenkins-and-the-git-branch-selection could leverage these as parameterized build sources, or parameterized builds could consume these variables directly.

Alternate solution:
GitHub plugin could skip over `getCandidateRevisions` call completely and trigger the build with the webhook's specified git hash / branch