I'm encountering the same issue.

In my job configuration a specific branch is configured (refs/heads/release_${ACTUAL_VERSION} - the version is defined as global environment variable in jenkins). But this job gets triggered on all changes to the repository, not only for changes to that specific branch (e.g. like merges in master).

Hi Mark, thanks for your report.
Could you please add reproduction information? Specifically:

• Your branch selector
• The repo (and branches you intend to match)
• What branches are actually being matched

I will also change the title of this ticket, as it points to the body of the webhook being ignored, as that suggests the fault rather than the symptom of the issue.
Thanks,
Martin

Doing a bit more digging into this issue, I've been able to replicate the behaviour on the first build of a freestyle job- specifying `feature-*` on a repo with two matching branches, if I push to one, both are built- but subsequent pushes only build the initial commit. This is intended behaviour, and has to do with the way branches are triggered.
You correctly identify, we don't use the webhook body to trigger an individual job. Rather, when we receive a webhook with a matching branch on initial commit, a git fetch gets a list of all branches- the SCM then identifies those that need to be build and builds them. You can see this in the logging of the first build of a job. Subsequent builds make the same check for any relevant refs, and typically there should only be a single branch to build, and ergo a single build made.
If you're seeing this behaviour regularly, and Jenkins is rebuilding the same commits over and over, that's definitely a bug- please send through the logs of those builds, as well as your detailed config information. If not, please let me know so I can close the ticket.

xpyrus Your issue I think is different to the one in this ticket- it sounds like non-matching branches are being built. This looks it might be a dupe of JENKINS-64557- maybe check, and if not, could you possibly file a separate bug ticket with steps to reproduce, and I'll take a look at it. Thanks!

You were able to reproduce the issue.  I did not wait to see if the build in my case reached a stable state because this was a migrated repo with several years of history.  Waiting for the plugin to walk the tree would have taken hours at best.  That is part of the reason I believe the behavior (intended or not) is a bug. A single webhook should not be capable of triggering a build storm.

Hi mbidewel,

As Martin mentioned previously, the behaviour of multiple builds triggering on initial push for wildcard branch config is intended behaviour. It is a feature of the jenkins git-plugin - if you have a look at the logs of the initial builds you can see the following output which is generated by the git-plugin as it detects multiple branches which match the wildcard:

Multiple candidate revisions
Scheduling another build to catch up with <<project>>

If you are looking for a way to disable this feature, there looks to be an open feature request for the git-plugin here.

However, I was not able to replicate the issue of subsequent pushes (after the initial one) triggering multiple builds. If this is still happening for you, can you provide us some logs of those builds as well as detailed config information so we can investigate further?

Thanks!

Haven't received a response here. I believe this was addressed in https://issues.jenkins.io/browse/JENKINS-61065- tested this with the added behaviour `Build single revision` and did not trigger a build storm.
This ticket also seems related, but it still open: https://issues.jenkins.io/browse/JENKINS-64557
Closing this ticket for now- please reopen if any issues are reoccurring.