bug#32575: [Cuirass] Filter results by architecture

[Clément Lassieur]

Ludovic Courtès <address@hidden> writes:

> Hi Danny & all,
>
> Danny Milosavljevic <address@hidden> skribis:
>
>> I think that for a portable package, the architecture it runs on is
>> an implementation detail - it should build on all of them.  If it doesn't,
>> that should show up as an error.
>>
>> So I had
>>
>>   hello      [x86_64-checkbox-log] [armhf-checkbox-log] 
>> [aarch64-checkbox-log]
>>
>> and not
>>
>>   hello.x86_64 [checkbox-log]
>>   hello.armhf [checkbox-log]
>>   hello.aarch64 [checkbox-log]
>>
>> The latter looks more like these are different packages with different 
>> purposes -
>> which they really aren't from a user standpoint.
>
> The difficulty is that, from Cuirass’ viewpoint, “hello.x86_64-linux”
> and “hello.armhf-linux” are just two different unrelated jobs.
>
> 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       

(10 evaluations means 40 jobs produced, etc.)

(Most of them have a derivation file associated that already exists, so
they won't be added in the Build table.)

I don't think we should change that meaning because it will make
everything more difficult to understand.

But the Builds table looks like this:

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.

Does it make sense?
Clément