bug#32575: [Cuirass] Filter results by architecture

["Clément Lassieur" <clement@lassieur.org>]

Ludovic Courtès <ludo@gnu.org> writes:

>> CREATE TABLE Builds (
>>   derivation    TEXT NOT NULL PRIMARY KEY,
>>   evaluation    INTEGER NOT NULL,
>>   job_name      TEXT NOT NULL,
>>   system        TEXT NOT NULL,
>>   nix_name      TEXT NOT NULL,
>>   log           TEXT NOT NULL,
>>   status        INTEGER NOT NULL,
>>   timestamp     INTEGER NOT NULL,
>>   starttime     INTEGER NOT NULL,
>>   stoptime      INTEGER NOT NULL,
>>   FOREIGN KEY (evaluation) REFERENCES Evaluations (id)
>> );
>>
>> We even have the 'system' column, so to me we have everything we need,
>> and we could display on one line all the builds that have the same
>> 'nix_name' for a given evaluation.
>
> Hmm, probably, indeed (though ‘nix_name’ is meant as hint, not as a
> key.)
>
> Right now, build-aux/hydra/*.scm returns a list of jobs like this:
>
>   (hello-2.10.x86_64-linux
>     (derivation
>       .
>       "/gnu/store/2dl7n4l0l0vjzpjnv67fbb7vf24kw0ap-hello-2.10.drv")
>     (description …)
>     (long-description …)
>     (license …)
>     (home-page …)
>     (maintainers "bug-guix@gnu.org")
>     (max-silent-time . 3600)
>     (timeout . 72000))
>   ;; … likewise for ‘hello.i686-linux’, etc.
>
> My proposal would be for build-aux/hydra/*.scm to return jobs that look
> like this:
>
>   (hello-2.10     ; <- no special naming convention
      ^
This is 'nix-name' (which is 'derivation-name')

>     (derivations
>       .
>       (("x86_64-linux" . /gnu/store/…-hello-2.10.drv")
>        ("i686-linux" . /gnu/store/…-hello-2.10.drv")))
              ^
This is 'system' (which is 'derivation-system')

>     (description …)
>     (long-description …)
>     (license …)
>     (home-page …)
>     (maintainers "bug-guix@gnu.org")
>     (max-silent-time . 3600)
>     (timeout . 72000))

So everything is already in the derivations that are in Cuirass.  Why
would we need to change the interface with the evaluator
(build-aux/hydra/*.scm)?

Clément

> Conceptually, that models the situation better, IMO.
>
> But like you write, we probably already have everything to do something
> along the lines of what Danny proposed.  The change above can come later
> (it would be incompatible with Hydra, too.)
>
> Thoughts?
>
> Ludo’.