If this is a problem of regular Multibranch scanning, we can avoid it via
https://www.jvt.me/posts/2020/02/23/jenkins-multibranch-skip-branch-index/:
```
// execute this before anything else, including requesting any time on an agent
if (currentBuild.getBuildCauses().toString().contains('BranchIndexingCause')) {
print "INFO: Build skipped due to trigger being Branch Indexing"
currentBuild.result = 'ABORTED' // optional, gives a better hint to
the user that it's been skipped, rather than the default which shows
it's successful
return
}
```
This will then allow us to avoid costly builds when the repo is resynced
but still perform builds when branches have been updated?
On Wed, 24 Nov 2021, 19:36 Damien Duportal, <[email protected]>
wrote:
> Thanks a lot Jesse for the explanation. I wasn't enough specific on the
> "why does the builds were started almost everyday", your explanation is
> what we understood, but using the crystal clear words :heart:
>
> By the way, the setting "Ignore rebuilding merge branches when only the
> target branch changed" had been applied to the organization scanning folder
> named "Tools", which include the BOM project. If it does not cause any harm
> in the next 7 days, we'll apply this to all the top level items on
> ci.jenkins.io.
>
> Thanks y'all for the feedbacks.
>
> Damien
>
> Le mardi 23 novembre 2021 à 21:19:28 UTC+1, Jesse Glick a écrit :
>
>> On Tue, Nov 23, 2021 at 2:32 PM Damien Duportal <[email protected]>
>> wrote:
>>
>>> As part of reducing the infrastructure costs, we would like to stop
>>> triggering builds of the pull requests on the BOM project when the target
>>> branch is updated (as suggested in
>>> https://issues.jenkins.io/browse/INFRA-1633 if I'm correct).
>>>
>>
>> Correct. I would recommend this change be made to *all* multibranch
>> projects on the site, but certainly heavyweight repos like `bom` are the
>> first priority.
>>
>> The rationale is that each daily organization scanning triggers a bunch
>>> of builds on this repository
>>>
>>
>> No, assuming webhooks have not been lost, scanning per se should not
>> trigger builds. Rather the problem is that a PR is merged, advancing the
>> base branch, and then every remaining open PR is rebuilt against that new
>> head.
>>
>> if an author of a pull request want their build to kick off, then they
>>> have to update their source branch.
>>>
>>
>> Yes, fine.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" 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-dev/ca11164f-d26d-4190-b875-acdb2f067a86n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/ca11164f-d26d-4190-b875-acdb2f067a86n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" 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-dev/CAP-iWuTPHjNGR1rk1F-hf1VDvmzdePW-QTgXK%2Bg2rS0Vizka7g%40mail.gmail.com.
