We have 2 jobs with different workspaces that do SCM polling every 2 minutes (with different filters) that could potentially be triggered at roughly the same time (as polling has a random fudge factor). If the longer job (5 minutes) runs first and then the other one will be polling as well, then it could happen that it polls one or two more times before it can actually run, the end result being that once the longer job finishes, the short job runs 3 times in a row, once with the change it should have been building, then two more times with no changes, but the logs will still say it was triggered because it did detect changes. Then as a bonus sometimes even the long job will run again with no changes, but a polling log saying that there were changes detected even though not saying which ones.

It gets worse still, as in this scenario sometimes it even builds a job when it should not have detected changes due to the filter we supplied and then to make it worse still also build that multiple times with no changes (same changelist number).

Then last of all, when a job does get triggered due to one out of many changes being filtered as positive, still all changes are reported to the job and not just the change that triggered it. Which is inconvenient for our slack notification code showing changes that were unrelated.

It is also unclear how to achieve the desired results if we were to switch to perforce triggers instead of polling, as the documentation is vague about the filters applying only to polling or also to p4 triggering.

We use a Jenkinsfile with scripted pipeline (not declarative) and as Jenkins UI for editing the script is not great and the serialization of the pipeline script to XML seems to be verbatim which seems dangerous for the XML parser to get confused, we have to (and prefer to) store the Jenkinsfile(s) in perforce as well. However the documentation on how polling and p4 workspaces work with "Pipeline script from SCM" is lacking or ambiguous and seems to have been tested and documented with declarative pipeline scripts only.

The end result is that in addition to jobs getting built when we do not want them to, our slack channel gets more notifications than it should which is disorienting to the team.