Ludovic Courtès <l...@gnu.org> writes: > Hi Danny & all, > > Danny Milosavljevic <dan...@scratchpost.org> 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
