is the branch indexing needed for the plugins ci.jenkins.io?

[Victor Martinez]

Hi there,

I've seen the branch indexing enabled for the plugins in ci.jenkins.io, and I'm not sure if this is needed or something that should be skipped in terms of reducing the cost of the infrastructure.

I did a quick search in the jenkins-infra org but I could not find any references to the GHOrganization that could answer my question.

Thanks

[Gavin Mogan]

I'm sorry i dont understand what your referring to. Do you mean that we do ci builds for each branch and pr? That seems like the main purpose of ci

What problem are you trying to solve?

--
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/c82620d0-4e7f-4b56-a3f9-19f66aadbcd9n%40googlegroups.com.

[Damien Duportal]

Hello Victor, would you be able to attend tomorrow's Infra session (or does it collide with yours?).

That would be a great discussion (sounds like webhooks and rebuild can be discussed and at least clarified)

Thanks a lot!

Damien

[Victor Martinez]

Hi

Hello Victor, would you be able to attend tomorrow's Infra session (or does it collide with yours?).

I think they don't clash, but I'm not sure though 

That would be a great discussion (sounds like webhooks and rebuild can be discussed and at least clarified)

+1 :) 

Thanks a lot!

np

 

I'm sorry i dont understand what your referring to. Do you mean that we do ci builds for each branch and pr? That seems like the main purpose of ci

Yes, you are right, ideally it should work like that but it's also expensive in terms of computing

What problem are you trying to solve?

I was curious about the existing configuration in the those projects and whether there was any threshold in terms of how often those branch indexing run and whether the obsoleted PRs should be part or not from that automation.

[Damien Duportal]

My bad, there isn’t any Infra session today 😱

When you say that branch indexing is computing expensive, what do you mean? 

I thought that scanning a repo was only a few API calls to GitHub (in this case with GitHub branch sources)?

Or is it related to the triggered builds (that triggers agents)?

For info, the VM hosting ci.jenkins.io is really beefy (8 vCPUs, 32 Gb) with an average resource usage around 55-60 %: computing does not seem to take a toll on the resource.

Thanks for looking into this Victor, it’s really nice and it helps covering as much hypothesis as possible!

To be fair, the job configuration is an upcoming topic once we’ll have started using Casc. Right now, the instance is still managed manually and it’s a pity because it makes collaboration and analysis really hard (impossible?).

But fear not mighty contributor, we’ll collaborate and improve this soon!

Damien

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/sdePILFgbsE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/80095481-d097-4240-aa11-d704be32f516n%40googlegroups.com.

[Victor Martinez]

My bad, there isn’t any Infra session today 😱

 

No problem

 

When you say that branch indexing is computing expensive, what do you mean? 

I thought that scanning a repo was only a few API calls to GitHub (in this case with GitHub branch sources)?

Or is it related to the triggered builds (that triggers agents)?

 

I was quite vague with the computing term, I meant from the builds point of view.

I understand the benefits for building every PR when the target branch has changes, but it's also a threshold in terms of how long a PR takes to be merged versus how many merges to the target branches are. A way to reduce the number of builds is to use a merge queue mechanism (manually or automated) therefore, only when those PRs should be merged the validation with the target branch will happen and therefore the PR will be merged if success. This approach reduces the number of builds quite a lot when the reviews takes time. 

 

For info, the VM hosting ci.jenkins.io is really beefy (8 vCPUs, 32 Gb) with an average resource usage around 55-60 %: computing does not seem to take a toll on the resource.

Thanks for looking into this Victor, it’s really nice and it helps covering as much hypothesis as possible!

To be fair, the job configuration is an upcoming topic once we’ll have started using Casc. Right now, the instance is still managed manually and it’s a pity because it makes collaboration and analysis really hard (impossible?).

But fear not mighty contributor, we’ll collaborate and improve this soon!

Thanks for the update

[Jesse Glick]

On Wed, Jun 30, 2021 at 11:34 AM Victor Martinez <victormar...@gmail.com> wrote:

I understand the benefits for building every PR when the target branch has changes, but it's also a threshold in terms of how long a PR takes to be merged versus how many merges to the target branches are. A way to reduce the number of builds is…

FYI INFRA-1633