bug#32575: [Cuirass] Filter results by architecture

bug#32575: [Cuirass] Filter results by architecture

[Ricardo Wurmus]

The Cuirass web interface shows the number of successful, failed, and
pending builds for each evaluation.  Looking at just these numbers it is
impossible to tell, how each of the supported architectures is affected.

It would be good if we could separate the view by architecture.  Then we
could more easily determine that a change broke many builds for one
architecture while fixing builds on another.

One way to do this would be to accept an optional query variable, e.g.

    http://ci.guix.info/jobset/guix-master?system=x86_64-linux

This could be selected from a drop-down on the page or exposed through a
number of links.

--
Ricardo

bug#32575: [Cuirass] Filter results by architecture

[Joshua Branson]

Ricardo Wurmus <rekado@elephly.net> writes:

> The Cuirass web interface shows the number of successful, failed, and
> pending builds for each evaluation.  Looking at just these numbers it is
> impossible to tell, how each of the supported architectures is affected.
>
> It would be good if we could separate the view by architecture.  Then we
> could more easily determine that a change broke many builds for one
> architecture while fixing builds on another.
>
> One way to do this would be to accept an optional query variable, e.g.
>
>     http://ci.guix.info/jobset/guix-master?system=x86_64-linux

That is an option.  Another one is using a REST API.  It seems to have
all the hype these days.  So the URL would turn into:

     http://ci.guix.info/jobset/guix-master/system/x86_64-linux

Though I freely admit, I don't completely understand the benefits of REST.

>
> This could be selected from a drop-down on the page or exposed through a
> number of links.
>
> --
> Ricardo

bug#32575: [Cuirass] Filter results by architecture

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

Joshua Branson <jbranso@fastmail.com> ezt írta (időpont: 2018. aug. 29.,
Sze, 22:41):

> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > The Cuirass web interface shows the number of successful, failed, and
> > pending builds for each evaluation.  Looking at just these numbers it is
> > impossible to tell, how each of the supported architectures is affected.
> >
> > It would be good if we could separate the view by architecture.  Then we
> > could more easily determine that a change broke many builds for one
> > architecture while fixing builds on another.
> >
> > One way to do this would be to accept an optional query variable, e.g.
> >
> >     http://ci.guix.info/jobset/guix-master?system=x86_64-linux
>
> That is an option.  Another one is using a REST API.  It seems to have
> all the hype these days.  So the URL would turn into:
>
>      http://ci.guix.info/jobset/guix-master/system/x86_64-linux
>
> Though I freely admit, I don't completely understand the benefits of REST.
>
> Actually there are some more options to do this, but I think this should
go with
a more generic filtering/sorting capability, using a uniform
implementation. I
noticed this in a writeup before, Ludo asked me to turn that to a TODO on
the Cuirass repository, and I will do that once back from vacation.

> >
> > This could be selected from a drop-down on the page or exposed through a
> > number of links.
> >
> > --
> > Ricardo
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2265 bytes --]

bug#32575: [Cuirass] Filter results by architecture

[Ricardo Wurmus]

Hi Joshua,

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> The Cuirass web interface shows the number of successful, failed, and
>> pending builds for each evaluation.  Looking at just these numbers it is
>> impossible to tell, how each of the supported architectures is affected.
>>
>> It would be good if we could separate the view by architecture.  Then we
>> could more easily determine that a change broke many builds for one
>> architecture while fixing builds on another.
>>
>> One way to do this would be to accept an optional query variable, e.g.
>>
>>     http://ci.guix.info/jobset/guix-master?system=x86_64-linux
>
> That is an option.  Another one is using a REST API.  It seems to have
> all the hype these days.  So the URL would turn into:
>
>      http://ci.guix.info/jobset/guix-master/system/x86_64-linux
>
> Though I freely admit, I don't completely understand the benefits of REST.

REST doesn’t quite apply here, because we only use GET — the Cuirass web
interface is read-only.  A big part of REST is to use HTTP verbs in an
appropriate manner and keep the URLs as resource identifiers the same
for all verbs.

What you refer to is the related trend to using Clean URLs:

    https://en.wikipedia.org/wiki/Clean_URL

These are often used with a RESTful API.

I think that filtering of a dynamic resource could very well be done
with a GET query string.  A Clean URL would make more sense for
something that doesn’t change as quickly (e.g. a particular product in a
catalogue).

--
Ricardo

bug#32575: [Cuirass] Filter results by architecture

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

Hi Ricardo,

On Wed, 29 Aug 2018 15:54:47 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> The Cuirass web interface shows the number of successful, failed, and
> pending builds for each evaluation.  Looking at just these numbers it is
> impossible to tell, how each of the supported architectures is affected.
> 
> It would be good if we could separate the view by architecture.  Then we
> could more easily determine that a change broke many builds for one
> architecture while fixing builds on another.
> 
> One way to do this would be to accept an optional query variable, e.g.
> 
>     http://ci.guix.info/jobset/guix-master?system=x86_64-linux
> 
> This could be selected from a drop-down on the page or exposed through a
> number of links.

I agree.

Also, in the Javascript frontend I had a list of architecture links for each package.

The filter could be applied to show only a given set of architectures.

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#32575: [Cuirass] Filter results by architecture

[Ludovic Courtès]

Hi Danny & all,

Danny Milosavljevic <dannym@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?

Ludo’.

bug#32575: [Cuirass] Filter results by architecture

[Clément Lassieur]

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

> Hi Danny & all,
>
> Danny Milosavljevic <dannym@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

bug#32575: [Cuirass] Filter results by architecture

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

bug#32575: [Cuirass] Filter results by architecture

[Clément Lassieur]

Ludovic Courtès <ludo@gnu.org> 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 "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
      ^
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 "bug-guix@gnu.org")
>     (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’.

bug#32575: [Cuirass] Filter results by architecture

[Mathieu Othacehe]

Hello,

The Builds table now has as "system" field on Cuirass master. The job
system is displayed on http://ci.guix.gnu.org/eval/xxx page. With
1ed93601089e774df849bc4ffab718bb1f142d34 it is also possible to sort by
table columns, including the "System" column.

Closing this one,

Thanks,

Mathieu