GNU bug report logs - #45006
cuirass: Add remote build support.

Previous Next

Full log

Message #20 received at 45006 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 45006 <at> debbugs.gnu.org
Subject: Re: [bug#45006] cuirass: Add remote build support.
Date: Mon, 21 Dec 2020 17:41:21 +0100

Hi Mathieu,

Thanks for the explanations.

On Mon, 21 Dec 2020 at 16:08, Mathieu Othacehe <othacehe <at> gnu.org> wrote:

>> Where are these specification_priority and package_priority configured?
>
> specification_priority comes from the new "#:priority" field in the
> Cuirass specification file and package_priority comes from the new
> "#:priority" field in the job structure.
>
> specification_priority ∈ [0, 9]
> package_priority ∈ [0, 9]
>
>  ⇒ build_priority ∈ [0, 99]
>
> where 0 is the maximal priority. When both specification_priority and
> package_priority are unset, the priority defaults to 99.
>
> I'm currently using the following priorities:
>
> modular: 1
> guix-master:2
> staging:3
> core-updates:4

Is this the specification_priority?

Where would the package_priority be defined?  A file mapping the package
name to the priority number?  Something else?


> The builds are picked according to their priority and then their
> timestamp, so that the most recent builds are picked first when the
> priorities are identical.

First are high priority, whatever the timestamp is, right?


> I don't have a strategy regarding package_priority yet.

Why do you need a package_priority strategy?  You only need a #:priority
strategy and a formula to compute it with the relevant parameters, here
specification_priority and package_priority.  Or I miss something.

In my understanding, the priority is given by something as:

 #:priority = f(specification_priority, package_priority, timestamp)

where, for example, once a week the queue is reevaluated to increase the
old; otherwise some could be blocked.


>> This removes part of issues about GC on The Big Store, right?
>
> Yes, this should allow to garbage collect way more aggressively the
> store on berlin and hopefully reduce the GC duration.

Really cool!

Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.