Thanks for the info Stephen.  I was not aware that the pollSCM trigger was 
ignored in a multibranch pipeline.  Something is polling for changes.  When 
someone pushes a change, a build gets triggered shortly thereafter.  I do 
agree with you that polling is evil and not scalable with many branches.  I 
would like to make things event driven.  Will need to investigate how with 
git.


On Tuesday, August 29, 2017 at 5:33:42 PM UTC-5, Stephen Connolly wrote:
>
>
> On Tue 29 Aug 2017 at 23:21, Stephen Connolly <stephen.al...@gmail.com 
> <javascript:>> wrote:
>
>>
>> On Tue 29 Aug 2017 at 22:35, Dallas Clement <dallas.a...@gmail.com 
>> <javascript:>> wrote:
>>
>>> If I click on the "Scan Multibranch Pipeline Now" link in the Jenkins 
>>> dashboard, it will kick off a build immediately even when there were no 
>>> changes.  I have my declarative Jenkinsfile configured to poll for SCM 
>>> changes.  I only want builds to be triggered from SCM changes.  Any idea 
>>> how I can suppress this behavior?
>>>
>>> pipeline {
>>>   agent any
>>>   options {
>>>     disableConcurrentBuilds()
>>>     timestamps()
>>>     buildDiscarder(logRotator(numToKeepStr: '8'))
>>>   }
>>>   triggers {
>>>     // Poll every 5 minutes for new changes
>>>     pollSCM 'H/5 * * * *'
>>>
>>
>> You do know in multibranch that this poll is ignored?
>>
>
> To explain why the design is this way:
>
> 1. Polling is evil
>
> 2. In most SCM implementations the poll for each branch is effectively a 
> redundant check, so if you have 10 branches all polling then Jenkins will 
> end up doing the *exact same* operation in a parallel batch of 5 (default 
> polling pool size) and follow up with another batch of 5... hammering the 
> SCM where one request would provide the answer for all 10 branches.
>
> 3. Branch API needs to maintain its own state as to the last revision 
> built. Polling will not update that correctly.
>
> 4. Polling for Git can be a mess due to how git can be configured to built 
> multiple branches in one job.
>
> So the decision is that polling is disabled on multibranch leaf jobs (if 
> you have a case where it is not disabled... congratulations you have found 
> a bug... likely not the one you thought, but a bug... polling should not 
> happen for leaf nodes of a multibranch project)
>
> You want to have indexing at a frequency such that if an event was lost, 
> you cannot go more than this long without the build (typically somewhere 
> between 4-24h for most people)
>
> You want event support to trigger the builds, not polling
>
>
>>   }
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkinsci-use...@googlegroups.com <javascript:>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/4dff0257-8170-4976-8998-13f20023e528%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/4dff0257-8170-4976-8998-13f20023e528%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> Sent from my phone
>>
> -- 
> Sent from my phone
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c4d93f77-80ec-4f7c-a783-0947fdb3af5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to