| We have a number of Pipeline jobs set up with automatic generation through Organization folders (both Stash and Github) and MultiBranch Pipelines generated from those (and finally PR/branch leaf jobs wherever Jenkinsfile's are found). Our default pipeline template includes an SCM polling setup (ranging from H/2 to H/15) because we don't have webhook ability due to corporate firewalling. Quite often I see builds of the same commit IDs running in parallel, or even the later build starting hours after an earlier one has finished (even if successfully). They often have different causes, such as "Started by an SCM change" vs. "Branch indexing". If a branch or PR has errors building (e.g. bad timing - new commit noticed in the original branch for a PR, but PR merged or closed during the half a minute or so while a build is preparing, so code can not be checked out - but MBP re-scanning did not yet happen to disable the job), then we can have hundreds of such failed rebuild attempts. During FOSDEM-2018 discussion with Andrew Bayer and Mark Waite (I'm not sure if we logged a ticket at that time) we concluded that such behavior is a bug, and that Jenkins is supposed to track in some matter which source commits it had processed (or even began processing - has queued or is building) and should avoid such automated duplicate re-runs of the same workload, regardless of whether the workspace (on an agent or master) is persistent or removed after each build. This does not happen often (e.g. every time), but sufficiently frequently to be noticeable and annoying (and sometimes expensive - e.g. if this kicks off the avalanche of product build and re-testing that costs several hours of blocked resources here and there). |
