BOM builds on ci.jenkins.io

[Damien Duportal]

Hello dear maintainers,

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).

The rationale is that each daily organization scanning triggers a bunch of builds on this repository, which is particularly heavy in term of resource consumption.

Of course, in this setup, if an author of a pull request want their build to kick off, then they have to update their source branch.

I'm writing this email since this setting as to be changed manually in the UI of ci.jenkins.io so I prefer asking: is there any voice against this change (specific to the BOM job) ?

For the infra team,

Damien DUPORTAL

[Mark Waite]

No objection from me to the proposed technique to reduce bom builds.

[Jesse Glick]

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.

[Damien Duportal]

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

[Jamie Tanna]

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?

--
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-de...@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.

[Jesse Glick]

On Wed, Nov 24, 2021 at 2:36 PM Damien Duportal <damien....@gmail.com> wrote:

the setting "Ignore rebuilding merge branches when only the target branch changed" had been applied…

That probably suffices as a workaround (I have not tried this plugin myself). FWIW my standard recommendation is to simply switch the Strategy for PR builds from Merging the pull request with the current target branch revision to The current pull request revision. There is not much point in using the PR-merge strategy if you are not doing fresh builds when the target branch moves, under the assumption PRs are usually based on the target branch head in effect at the time the PR was filed and that pushes of follow-up commits also include merges of the target branch as needed, since you are no longer reliably verifying that PR tests pass against the current target branch head before merging; and the PR-merge strategy has downsides other than performance, such as preventing Incrementals deployment when an actual merge is being built, and preventing lightweight (API-based) checkout of `Jenkinsfile`. The PR-head strategy is simpler to understand, and does not require a special plugin to avoid overhead.