-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Jenkins 2.125, Ubuntu 14
When the pollSCM in a declarative pipeline is executed when the jobs on the same commit is queued and did not do a checkout scm the jobs is queued again on the same commit.
A test Jekninsfile:
pipeline { agent { node { label 'local' } } triggers { pollSCM('H/2 * * * *') } stages { stage('Run') { steps { checkout scm sh 'sleep 1000' } } } }
If a new commit is pushed within in 1000 seconds and the executors on jenkins are busy jenkins will fire a new job at each pollSCM till 1 job on this commit did do a checkout. In this example this will be 5-6 jobs on the same commit.
When doing this on multiple repositories on a limited number of executors this will explode in 10000+ jobs if your unlucky. (happened to me)
PIpeline intentionally allows multiple concurrent builds of the same commit. Freestyle jobs block the polling while a job is running but that also prevents them from being used to test different commits concurrently.
In this case, the preferred solution is to notify Jenkins from the git repository through either the notifyCommit API or with a webhook (as in GitHub, Bitbucket, Gitea, etc.). Refer to the "polling must die" blog post for the description why polling is less efficient and less effective than having the repository notify Jenkins on each change.
I think this should be closed as "Won't Fix", though there might be some way to extend the Pipeline syntax to specifically disallow concurrent builds of the same git commit. I won't be creating that type of Pipeline syntax extension.