Clément Lassieur <clem...@lassieur.org> skribis:
> Ludovic Courtès <l...@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’.
