Cuirass enhancements

Cuirass enhancements

[Björn Höfling]

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

Hi Guix,

I was a bit sad that Hydra is down now, because I really got used to
its interface. Thanks to Mark and all others who made their fingers
dirty on that machine. After a little chat on IRC, I decided to compare
Cuirass with Hydra and wrote down what I'm missing or find
uncomfortable in its daily usage.

I think I'm pretty good at pulling apart other people's software and
can be quite picky. So, let me say that I really appreciate what all
contributors have done so far and take this as suggestions for
enhancements.

It might also just be the case that I missed something and what I want
is already implemented in a different way.

After some discussions, I could add this as little, compact bugs into
Debbugs. If you know of already existing bugs, it would be nice if you
could mention them.

Homepage/Specifications list:

* The list of specifications should be ordered alphabetically by its
name.
* The specification and input seams to be redundant. Why?:
("staging-staging	INPUT: staging (on staging)"
* A description would be nice to better understand the use of that
specification.

Clicking into a specification gives a list of evaluations, like here:
https://ci.guix.gnu.org/jobset/guix-master

In that list:

* I'm missing a column with start-date of that evaluation.
* Right now, I see one evaluation where column "Success" being "In
progress ..."
The next evaluations have three colored numbers, in green, red and grey.
When I remember it correctly from Hydra, then "grey" would mean
"queued." But then the term "In progress ..." is a bit misleading, as
those with items in queue are also "In progress ...".

If I understand it right, maybe "Preparing ..." would be a better term?

* [unimportant]: The evaluation lists an input change. It would be nice
to directly point to the new commit (and old commit?). That said, it
could get complicated, as Cuirass is a general build system and not
every git repository has a public interface. Thus, we might need to add
another configuration to the input data-structure, like
"webinterface-uri". Sounds more complicated than worth the efford?

Going into one evaluation, like
https://ci.guix.gnu.org/eval/5874

* It would be nice if the summary of good/bad/queued numbers is repeated
in the header.
* The table should be sorted by job name.
* I'm missing a "completion time" for failed jobs. I mean there must be
some instance in time when failure was evaluated.
* I'm really missing the tabs/filters like in Hydra: "succeding",
"newly succeding", "newly failing", ...
In having all jobs in one big list is annoying. I care usually only
about failures.
* If a job failed because of its dependency, I would like to see which
one caused the problem. I don't know how to find that out.
In Hydra, the name and build log of the failing dependency was directly
available.

Job search:

It's nice that there is a search now, but it's not enough for me :-)

The search string disappears from the search box. It would be very nice
if it would be kept, then I can remember and refine it if necessary.

I would like to see a "build series" for a specific job/system
combination.

For that, In Hydra I searched for the job name. It first presented me
with a list of
"types", like "maven: master/i386" or "maven: staging/x86_64".

Then I had to click one of them to see that specific series.

In the Curiass search, I only have a fulltext search, I cannot choose
the system.

How would I find the proper "maven", not all the "maven-*" packages?

In Hydra, there is a link to this "build series":

https://hydra.nixos.org/job/nixpkgs/staging-next/maven3.x86_64-darwin

Even if I find it hard to get to my specific package by search, I can
modify that link to get to my package (and add a bookmark for my loved
package :-)).


Scrolling:

* I would like to know that I'm on page k/n.
* When scrolling through lists, the semantics of "first/prev/next/last"
is not the way I expect it, at first I thought it is totally broken.

For example this evaluation:

https://ci.guix.gnu.org/eval/5862?border-high-time=1560824784&border-high-id=1398865

I'm at the first tab. "Previous" is greyed out. Then I would expect
"First" also to be greyed out: If I cannot go any further back, I am on
the "First" tab (linear, consecutive order of tabs assumed :-))

Even worse at the end: I can click four times on "Next", and then be at
a page that shows only three jobs (the total number of jobs is not
always dividable by the number of jobs per page, so the last page
usually has a smaller remainder to show):
https://ci.guix.gnu.org/eval/5862?border-high-time=1560816540&border-high-id=1398862
So, I cannot go any NEXTer, that button is greyed out. As with the
beginning, I'm expecting to be already on the LAST page. But the button
is clickable. And when I click it, I will receive a FULL PAGE! It took
me a while to figure out that nothing too bad happened: I'm getting the
last n entrys (where n is the number of elements per page, being 10
here). I can even the hit the "LAST" button, luckily only the page gets
reloaded.

Björn

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

Re: Cuirass enhancements

[Ricardo Wurmus]

Hi Björn,

> I would like to see a "build series" for a specific job/system
> combination.
>
> For that, In Hydra I searched for the job name. It first presented me
> with a list of
> "types", like "maven: master/i386" or "maven: staging/x86_64".
>
> Then I had to click one of them to see that specific series.
>
> In the Curiass search, I only have a fulltext search, I cannot choose
> the system.

You can.  E.g. “r-minimal system:armhf-linux spec:guix-master”.

It’s not documented (what’s new…?), but it was the first thing I wanted
after implementing the search itself.

-- 
Ricardo

Re: Cuirass enhancements

[Ricardo Wurmus]

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> writes:

> Homepage/Specifications list:
>
> * The list of specifications should be ordered alphabetically by its
> name.

Done.

-- 
Ricardo

Re: Cuirass enhancements

[Ricardo Wurmus]

Hi Björn,

> * I'm really missing the tabs/filters like in Hydra: "succeding",
> "newly succeding", "newly failing", ...
> In having all jobs in one big list is annoying. I care usually only
> about failures.

Cuirass now has tabs, though it won’t show “newly” succeding or failing
jobs.  It just splits them by state, which is an improvement over having
just one big list.

(The “Scheduled” tab isn’t currently working, will look into this
later…)

--
Ricardo

Re: Cuirass enhancements

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Björn,
>
>> * I'm really missing the tabs/filters like in Hydra: "succeding",
>> "newly succeding", "newly failing", ...
>> In having all jobs in one big list is annoying. I care usually only
>> about failures.
>
> Cuirass now has tabs, though it won’t show “newly” succeding or failing
> jobs.  It just splits them by state, which is an improvement over having
> just one big list.
>
> (The “Scheduled” tab isn’t currently working, will look into this
> later…)

This works now.

-- 
Ricardo

Re: Cuirass enhancements

[Björn Höfling]

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

On Wed, 19 Jun 2019 10:23:57 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> Ricardo Wurmus <rekado@elephly.net> writes:
> 
> > Hi Björn,
> >  
> >> * I'm really missing the tabs/filters like in Hydra: "succeding",
> >> "newly succeding", "newly failing", ...
> >> In having all jobs in one big list is annoying. I care usually only
> >> about failures.  
> >
> > Cuirass now has tabs, though it won’t show “newly” succeding or
> > failing jobs.  It just splits them by state, which is an
> > improvement over having just one big list.
> >
> > (The “Scheduled” tab isn’t currently working, will look into this
> > later…)  
> 
> This works now.
> 

Hi Ricardo,

that's so fast :-)

Thank you, looks good.

Björn

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

Re: Cuirass enhancements

[Ricardo Wurmus]

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> writes:

> It's nice that there is a search now, but it's not enough for me :-)
>
> The search string disappears from the search box. It would be very nice
> if it would be kept, then I can remember and refine it if necessary.

This is now implemented.

-- 
Ricardo

Re: Cuirass enhancements

[Ricardo Wurmus]

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> writes:

> * If a job failed because of its dependency, I would like to see which
> one caused the problem. I don't know how to find that out.
> In Hydra, the name and build log of the failing dependency was directly
> available.

This is now implemented on the “details” page.  The logs of the failed
prerequisites are linked directly.

(We don’t keep that kind of information in the database, so we don’t
know what *build* relates to the failure.  We get that information in a
round-about way through the derivation of the build and the Guix
derivations API.)

--
Ricardo

Re: Cuirass enhancements

[Danny Milosavljevic]

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

Hi Björn,

On Tue, 18 Jun 2019 19:50:25 +0200
Björn Höfling <bjoern.hoefling@bjoernhoefling.de> wrote:

> * I would like to know that I'm on page k/n.

That web interface is a frontend to a dynamically changing database
(and a quickly changing database at that).

What would "page" even mean there?

And the "/n" part is impossible to keep constant because the database changes
and so does n.
So the "/n" part on the display would keep changing--and it would be correct
in doing so.  Furthermore, the page number you are *on* would also keep
changing.

Even if there were fixed-layout "page"s, the way the database is
structured means that having pagination show a fixed number of items
per page at all is difficult to do (cuirass tries to do it).

Alternatively, the server could keep a serializable transaction
open per client session.
Then you just wouldn't see new builds until you somehow restarted your
client session (HTTP is stateless--so more fakery necessary there).
Then you can have page numbers :)

> I'm at the first tab. "Previous" is greyed out.

I don't like this graying out business.  It's perfectly possible that a new
entry appeared in the database that is now (because of the sorting) before what
you thought was the first page (because back then when you queried the page it
*was* the first page--emphasis on "was")--and now you can't get to it.

> Then I would expect
> "First" also to be greyed out: If I cannot go any further back, I am on
> the "First" tab (linear, consecutive order of tabs assumed :-))

I've made "First" and "Last" behave the way you expect in cuirass commit
d5b827097b456100039370003899ec7ad04ac934.  However, that is not
an endorsement of graying out.  I just like consistency.
 
> Even worse at the end: I can click four times on "Next", and then be at
> a page that shows only three jobs (the total number of jobs is not
> always dividable by the number of jobs per page, so the last page
> usually has a smaller remainder to show):
> https://ci.guix.gnu.org/eval/5862?border-high-time=1560816540&border-high-id=1398862
> So, I cannot go any NEXTer, that button is greyed out. As with the
> beginning, I'm expecting to be already on the LAST page. But the button
> is clickable. And when I click it, I will receive a FULL PAGE! 

Yeah, well, pages don't exist and cuirass in imperfectly faking them.

I'd go back to first principles and ask what problem the paging is supposed to
solve, then solve it in a different way.  It's already very different to what
book pages would be.

Suggestions welcome.

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

Re: Cuirass enhancements

[Ricardo Wurmus]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Tue, 18 Jun 2019 19:50:25 +0200
> Björn Höfling <bjoern.hoefling@bjoernhoefling.de> wrote:
>
>> * I would like to know that I'm on page k/n.
>
> That web interface is a frontend to a dynamically changing database
> (and a quickly changing database at that).
>
> What would "page" even mean there?

Since real constant pages are impossible (or can only be approximated)
I’d like to know just how far to the beginning or end I am.

It doesn’t need to be a number.  If it was just a line at the bottom
with a marker near the beginning, the middle, or the end, and adjusting
its position as I go to the next or previous page I’d already be happy.

--
Ricardo

Re: Cuirass enhancements

[Björn Höfling]

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

On Wed, 19 Jun 2019 21:49:50 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > On Tue, 18 Jun 2019 19:50:25 +0200
> > Björn Höfling <bjoern.hoefling@bjoernhoefling.de> wrote:
> >  
> >> * I would like to know that I'm on page k/n.  
> >
> > That web interface is a frontend to a dynamically changing database
> > (and a quickly changing database at that).
> >
> > What would "page" even mean there?  
> 
> Since real constant pages are impossible (or can only be approximated)
> I’d like to know just how far to the beginning or end I am.
> 
> It doesn’t need to be a number.  If it was just a line at the bottom
> with a marker near the beginning, the middle, or the end, and
> adjusting its position as I go to the next or previous page I’d
> already be happy.

You are right Danny, I haven't considered the fact that content changes
(at least for the not yet finished evaluations). I like Ricardo's idea:
I don't care about being exaclty on page 23/204. I just want some
notion of where I am: At the beginning, the end, or roughly somewhere
in between.

Still I like the greyed-out buttons to know that I'm really at the
beginning/end, and that the buttons are consistent.

Björn

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

Re: Cuirass enhancements

[Ludovic Courtès]

Hello!

I’d just like to say that we should think not just in terms of a web
interface, but also in terms of an HTTP API + CLI/Emacs.

Things like ‘guix challenge’, ‘guix weather’, and build-farm.el are
pretty nice to me as a user, so I think we should keep an eye on how we
can make such tools possible as we enhance Cuirass.

I’d also like to say thanks to Ricardo for all the commits that have
gone into Cuirass lately!  Looks like your prodding has been rather
efficient, Björn.  :-)

Ludo’.

Re: Cuirass enhancements

[Björn Höfling]

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

On Fri, 21 Jun 2019 17:18:38 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Hello!
> 
> I’d just like to say that we should think not just in terms of a web
> interface, but also in terms of an HTTP API + CLI/Emacs.

+1

Would you like to formulate out a bug with what you are missing?
 
> Things like ‘guix challenge’, ‘guix weather’, and build-farm.el are
> pretty nice to me as a user, so I think we should keep an eye on how
> we can make such tools possible as we enhance Cuirass.
> 
> I’d also like to say thanks to Ricardo for all the commits that have
> gone into Cuirass lately!  Looks like your prodding has been rather
> efficient, Björn.  :-)

Yes, thank you Ricardo. This is now much more usable than before. While
playing around with the new features, I found some more things that
could be enhanced. So, more prodding to be expected :-)

Björn

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