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 <[email protected] 
> <javascript:>> wrote:
>
>>
>> On Tue 29 Aug 2017 at 22:35, Dallas Clement <[email protected] 
>> <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 [email protected] <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 [email protected].
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