Recent versions of Atlassian's Stash Webhook to Jenkins specify always the "branches" argument and optionally the "sha1" argument when triggering. This leads to the the two following problems:

Case 1: the webhook is configured not to send the sha1 argument

When a job is set to build Stash pull-requests, Stash passes the branch name to which the pull request has been created. The Jenkins job does not however list this branch and is therefore not triggered. If the job were configured to be triggered for any branch name, it would also be triggered for other reasons than pull-requests.

Case 2: the webhook is configured to send the sha1 argument

If the sha1 is part of a pull request instead of a branch, this commit ID is invisible to any Jenkins job that is not specifically fetching the non-standard 'refs/pull-requests/*' refs from Stash. The job may still be triggered (e.g., because the "branches" argument matches the job's configuration regarding branches) but it will fail when checking out the given commit ID, because it is not found (see e.g., JENKINS-25049).

To solve these two problems, it would be useful to have two additional, per job configuration options for the the git plugin that apply when deciding whether a job should be triggered or not:

• Ignore the "branches" argument coming from the notifyCommit HTTP request
• Ignore the "sha1" argument coming from the notifyCommit HTTP request