[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32575: [Cuirass] Filter results by architecture
From: |
Clément Lassieur |
Subject: |
bug#32575: [Cuirass] Filter results by architecture |
Date: |
Fri, 31 Aug 2018 20:35:32 +0200 |
User-agent: |
mu4e 1.0; emacs 26.1 |
Ludovic Courtès <address@hidden> 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 "address@hidden")
> (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 "address@hidden")
> (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’.