we have a github repo that contains close to 5000 git tags, the jenkins job is configured to be triggered by webhook push and recent upgrade of jenkins we hit this change https://github.com/jenkinsci/git-plugin/commit/31fedce9c41c9006c886835e03c9fe825d49aba6 which caused our scm polling time increases from 20 seconds to up to 5 minutes because we set some regex filter for branches matching and that change now extend that matching to tags too. and as a result I've seen duplicate build being triggered by the same github push notification.

All duplicated build jobs has the same scm polling log (same webhook notification) which lead me believe that there are multiple polling threads responding to the same webhook notification and they are not acting in a thread safeway to decide if there are new changes to build. I am looking at this line: https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/com/cloudbees/jenkins/GitHubPushTrigger.java#L109 and suspect that this could be the potential cause, since multiple thread can enter the poll and trigger the new build before the lastBuild being updated (I am not super familiar with the code base so apologize if I am missing the target here)

one more thing to mention is that after I drop all the branch matching in my jenkins job configuration to put the scm polling time back too less than 1 sec, there will no longer be any duplicated build.