We mighty try this https://github.com/quarkusio/quarkus/issues/33467#issuecomment-1555245980
On Thu, Aug 1, 2024 at 4:13 PM Francisco Javier Tirado Sarti < [email protected]> wrote: > In this particular case, there is no human culprit. > I guess the issue is that our Jenkins is so slow, that many times the > keycloak image timeout expires. > Maybe there is a way to increase it. > > On Thu, Aug 1, 2024 at 3:50 PM Paolo Bizzarri <[email protected]> wrote: > >> Hi Francisco, >> >> ideally yes. But some jobs are executed only every night or every x >> hours, >> so someone has to take care of them and check what could be the potential >> culprit. >> >> For example, in a nightly, it is not obvious who has broken the build. >> >> In a case like this >> >> >> https://ci-builds.apache.org/job/KIE/job/kogito/job/10.0.x/job/nightly/job/kogito-examples.build-and-deploy/17/ >> >> where we have a test that keeps failing almost every day, it is not clear >> to me who is the culprit. >> >> I can raise the issue to the SMEs and ask them to have a look and decide >> who is the best to take care of it. >> >> regards >> >> Paolo >> >> >> On Thu, Aug 1, 2024 at 3:23 PM Francisco Javier Tirado Sarti < >> [email protected]> wrote: >> >> > I think one alternative to human supervision will be to send an e-mail >> to >> > the author of the PR that breaks the build. >> > Problem is that we still have some (not much) flaky tests and it is >> unclear >> > if we will have false positive reports. >> > Anyway, personally, I would like to be informed as soon as possible if >> one >> > of my authored PRs has broken the build, so I can fix it urgently. >> > >> > On Thu, Aug 1, 2024 at 3:09 PM Paolo Bizzarri <[email protected]> >> wrote: >> > >> > > Hello kie mates, >> > > >> > > please find my proposal in the following. >> > > >> > > PROBLEM >> > > - builds are often broken and they stay broken for a long time. There >> > seem >> > > to be not a clear definition of who should take care of this >> > > >> > > CONTEXT >> > > - fixing builds is slow, annoying and tipically is more a job of >> chasing >> > > someone else than fixing it yourself. So it becomes quickly wearing. >> > > >> > > PROPOSED SOLUTION >> > > - identify a number of build sheriffs that look at the various builds, >> > open >> > > the relevant issues for tracking and chase other devs and >> contributors to >> > > fix the issues themselves. The sheriffs are not supposed to fix >> > everything >> > > by themselves, but instead to keep the attention of other developers >> on >> > the >> > > status of the builds. >> > > I suggest we have three sheriffs, that stay around for one month and >> > then >> > > pass the token to someone else: one for drools and optaplanner, one >> for >> > > kogito, one for kie-tools. >> > > >> > > Let me know your ideas and feedback. >> > > >> > > Regards >> > > >> > > Paolo >> > > >> > >> >
