bug#32575: [Cuirass] Filter results by architecture

[ludo@gnu.org (Ludovic Courtès)]

Clément Lassieur <clement@lassieur.org> skribis:

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

[...]

>> Perhaps what we would need is to internally change how jobs are
>> represented in the database: we could have one job, “hello”, connected
>> to one or more “builds”, each with its own system.
>>
>> I think it would amount to splitting the “Builds” table into two tables:
>> “Builds” and “Jobs”.  Clément, does that make sense?
>
> The 'job' word already has a meaning in Cuirass: it is the thing that is
> returned from the evaluation.  For example, if Cuirass builds foo and
> bar for x86_64 and i686, there will be exactly 4 jobs produced at each
> evaluation :
>
>  - foo.x86_64-linux     
>  - foo.i686-linux       
>  - bar.x86_64-linux     
>  - bar.i686-linux       

Yes.

> 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
    (derivations
      .
      (("x86_64-linux" . /gnu/store/…-hello-2.10.drv")
       ("i686-linux" . /gnu/store/…-hello-2.10.drv")))
    (description …)
    (long-description …)
    (license …)
    (home-page …)
    (maintainers "bug-guix@gnu.org")
    (max-silent-time . 3600)
    (timeout . 72000))

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’.