Hi all, I don't really remember why pull request builds were enabled on Jenkins, we use Jenkins for the ability to publish the website only.
Anyhow, https://ci-builds.apache.org/job/Camel/job/Camel.website/ should now only build for changes on `main`. zoran On Mon, Feb 26, 2024 at 9:55 AM Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Yeah … that’s a good idea … also what we are doing in other projects. > > Generally, we only build on Jenkins for utilizing the ability to deploy > artifacts (SNAPSHOTS) or update our website on Jenkins. > So, I like this idea. > > Chris > > Von: Claus Ibsen <claus.ib...@gmail.com> > Datum: Freitag, 23. Februar 2024 um 12:43 > An: dev@camel.apache.org <dev@camel.apache.org> > Betreff: Re: Excessive use on the "git-websites" runners? > Claus Ibsen > ----------------- > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > > > On Fri, 23 Feb 2024 at 12.34, Zoran Regvart <zo...@regvart.com.invalid> > wrote: > > > 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? > > > > Yes that is a good idea > > > > 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 > > -- Zoran Regvart
