Hi Thorsten,
I've modified the condition logic a little bit. Originally, gerrit_master
will run if SUCCESS or "jenkins:all" is set, but gerrit_master_seq will run
if not SUCCESS, so it may run again when "jenkins:all" is set.
Now, I've added another condition ("jenkins:all" is not set) for
gerrit
Hi Baole,
Baole Fang wrote:
> Hi Thorsten,
>
> After quickly checking the gerrit_master_ml and gerrit_master_seq
> configuration, I didn't notice the change. Can you indicate the change for
> me?
>
Sure - look into
https://ci.libreoffice.org/view/Gerrit/job/gerrit_master_ml/configure
, and searc
Hi Thorsten,
After quickly checking the gerrit_master_ml and gerrit_master_seq
configuration, I didn't notice the change. Can you indicate the change for
me?
Besides, I've looked into the gerrit_master_android and have a rough idea
to integrate "jenkins:all" into gerrit_master_ml.
Best,
Baole Fa
Hi Noel,
I wrote:
> I can try & sit down tomorrow (with Baole, and perhaps you can join
> too?), and tweak things a bit.
>
Added a tweak to short-circuit the ML builder, to unconditionally run
the old 'normal' setup, if the patch has this gerrit topic set (minus
the quotes): "jenkins:all".
Ponde
Hi Thorsten,
I'm still traveling tomorrow. What time would you like to meet? I'll see if
I can make it.
Best,
Baole Fang
On Mon, Aug 21, 2023 at 4:52 PM Thorsten Behrens
wrote:
> Hi Noel,
>
> Noel Grandin wrote:
> > Even in the good case, in the unlikely event of builds passing on the
> first
Hi Noel,
Noel Grandin wrote:
> Even in the good case, in the unlikely event of builds passing on the first
> run, we have doubled the latency from submitting to getting a jenkins pass,
> since we are running the two slowest build sub-paths in sequence.
>
The idea is to run a fast & reliable build
HI
I don't see how this can be an improvement for devs, compared to the simple
expedient of simply getting more hardware (and it is not like TDF is
hurting for the necessary cash right now)
Even in the good case, in the unlikely event of builds passing on the first
run, we have doubled the latenc
Hi Kohei,
There are two models. One model is responsible for predicting the
probability of each unit test to fail, and the other is predicting the
overall probability of the patch to fail any unit test. The first has a
failure recall of 95% (meaning 95% failures are captured) and a success
recall
Hi y'all,
Xisco Fauli wrote:
> On 18/8/23 18:48, Noel Grandin wrote:
> > Just recently I have to resume my builds 5 or 6 times to get past the ML
> > stage, only then to discover that I made a mistake that affected some
> > other platform, and then having to change things again, and restart the
>
Hello,
On 18/8/23 18:48, Noel Grandin wrote:
Just recently I have to resume my builds 5 or 6 times to get past the
ML stage, only then to discover that I made a mistake that affected
some other platform, and then having to change things again, and
restart the process.
Maybe having a way to
> On 18 Aug 2023, at 6:21 PM, Baole Fang wrote:
>
> Hi Noel,
>
> The reason to choose it is that it is most likely to fail among all the
> builds. If it fails, then there is no need to run others.
This assumes it is failing because something in the change being built, but it
often fails fo
HI
My problem with this design assumes that the only thing we are optimising
for is reducing the load on the build servers.
But we are not a build-service organisation. Jenkins is a service that is
subordinate to the needs of developers.
And what developers need is feedback about which platforms
Hello,
On 09.08.2023 10:57, Baole Fang wrote:
Feel free to contact me if you have any questions!
Just out of curiosity, what is the overall accuracy of your model? Do
you have a confusion matrix or something similar that shows the
performance of your model?
Thanks,
Kohei
Hi Noel,
The reason to choose it is that it is most likely to fail among all the
builds. If it fails, then there is no need to run others. If we choose a
job that is stable and likely to pass every patch, then all other builds
also need to be run, saving no computation.
I'm open to all advice on
Hi
Why are we fronting the ml jenkins job with the least reliable subjob?
Surely we should be using the gcc job - which is faster and more reliable.
Regards, Noel Grandin
15 matches
Mail list logo
