Hi Chris, Cameleers, chiming in a bit late, apologies for that. I don't think we need to build PR builds on Jenkins. We already build on GitHub Actions and (when netlify CLI gets fixed) get previews there. I'd like to disable building branches other than main on Jenkins. I think this should help quite a bit with the queue depth on Jenkins.
Thoughts? zoran On Tue, Feb 20, 2024 at 11:13 AM Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Hi all, > > Guess our release is out and the website was updated before that … so guess > I’m fine. > And if you say that this is an unusual case, I also see no problems. > From my perspective it just looked as if every PR was blocking a runner and > that would have been a problem, of course. > > If that’s not the case, I guess there’s no big problem. But limiting the > parallel usage of these runners is of course a good idea anyway. > > Chris > > Von: Claus Ibsen <claus.ib...@gmail.com> > Datum: Montag, 19. Februar 2024 um 13:43 > An: dev@camel.apache.org <dev@camel.apache.org> > Betreff: Re: Excessive use on the "git-websites" runners? > Hi > > Yeah ideally those CVEs should be in 1 merge to main - so they were > released together. > > And frankly the website is rebuild from scratch each time, instead of being > able to update only parts of it. > The CVEs only affect the security page + a new page per CVE. > > I stopped one of the builds, as there is a 2nd build in the queue to > publish the last CVE. > That should put your job ahead of ours. > > > > > > On Mon, Feb 19, 2024 at 1:37 PM Andrea Cosentino <anco...@gmail.com> wrote: > > > I don't think it would work on our website, but Zoran could have more > > information about this. > > > > What we could do, it's maybe limit the number of builds on git-websites > > nodes concurrently. > > > > Il giorno lun 19 feb 2024 alle ore 13:30 Christofer Dutz < > > christofer.d...@c-ware.de> ha scritto: > > > > > Hi, > > > > > > as the PLC4X build also uses that, perhas what we did would be also an > > > option for you? > > > We build the website on our own VM, but stash the built website … then on > > > the git-websites agent, we simply unstash what was built on our VM and > > > deploy that … this reduces the lock we have on shared infra to the > > minimum > > > … We’re also doing the same with deploying snapshots: We build on our VM > > > and use one of the ubuntu agents to deploy. > > > > > > Cause running a build on a PR, should probably not require staging of > > > website changes … as soon as the PR is merged, then of course. > > > > > > Chris > > > > > > > > > Von: Andrea Cosentino <anco...@gmail.com> > > > Datum: Montag, 19. Februar 2024 um 13:20 > > > An: dev <dev@camel.apache.org> > > > Betreff: Re: Excessive use on the "git-websites" runners? > > > Usually there is not that much activities. There were 3 PRs related to > > cves > > > and some related to the last release done during the weekend. So this > > > should be just a temporary saturation. We don't have other way of > > > publishing the website except using that mechanism. > > > > > > Il lun 19 feb 2024, 13:13 Christofer Dutz <christofer.d...@c-ware.de> ha > > > scritto: > > > > > > > Hi all, > > > > > > > > I’m currently trying to finish up some stuff for the upcoming PLC4X > > > > release. However am having problems because every time I want to update > > > our > > > > website, I have to wait a long, long time, because all 3 runners in the > > > > “git-websites” class (websites1, websites2 and websites3) are blocked > > > with > > > > really long running builds of Apache Camel. > > > > > > > > Most all have the tags associated with PRs … so I am asking myself: Do > > > > these builds have to be on git-websites? If not … it would be > > appreciated > > > > if you wouldn’t keep on blocking all runners. Of is currently something > > > out > > > > of the ordinary going on? > > > > > > > > Chris > > > > > > > > > > > > -- > Claus Ibsen > ----------------- > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Zoran Regvart
