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, <damien.dupor...@gmail.com>
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 <damien....@gmail.com>
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAP-iWuTPHjNGR1rk1F-hf1VDvmzdePW-QTgXK%2Bg2rS0Vizka7g%40mail.gmail.com.
