> > 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 -- 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/e9470f78-0117-4a70-beed-3a70245aac79n%40googlegroups.com.
