mercredi 6 avril 2011

Buildd status pages: say goodbye to external dependencies

Last week, I had to put my daily (real) work off for a bit, to get some rest.  I took this occasion to implement a few ideas I had for the Buildd Status Pages. Mainly, I wanted to get rid of my external dependencies which are:

  • which shows all build logs available for a package. It's nice and simple, but old and not easy to read. In my opinion, it's almost useless because it takes some time to realize (visually) what happened to the package (there are no colors to distinguish successful builds from failures, text is not aligned, etc…).

  • which shows the content of a build log given a package, a version, an architecture and a time-stamp identifying the log file (you can see this as an example). The page works, there is no real need to rewrite it, modify it or whatever. It just does its job perfectly, but it was my last external dependency :)

Besides of getting rid of external dependencies, there were also a few feature requests (#618676, #612174, #518526) waiting for a while and it was good time to fix them. Hopefully, there are related to what I was fixing.

The final version is now deployed and can be used. The implemented changes are :

  • From the regular package view, you have now a link to all logs available for that packages (click on Logs in the table), or all logs for a specific architecture (click on old in the table, for you preferred architecture).

  • The listing of available build logs has now its own new page. The default listing shows everything, i.e. every version available and everywhere known architecture (just like the old page did before). But now, you get with that the build time and disk space consumed during the build, when available. Furthermore, it groups the logs by version so that it becomes easier to see that "all that group are logs for the same version". And you can also show build logs for a specific architecture by choosing one (links in rows) ; or restrict on versions, in a similar way. And, of course, there are some additional colors in each row to distinguish successful builds from those who failed.

  • The page that fetches the log is now available from other pages. And this removes the last external dependency.

  • All pages have an appropriate HTML title set (yeah, it's a shame that I didn't fix that since the first deployment).

I think that I tested well enough this new version and it works okay. Nevertheless, if you encounter a bug or a strange behavior, please don't hesitate to contact me (either by mail or on irc) or submit a bug report against

The next steps (probably) are :

  • add the last feature that pkg.cgi has which the ability to select a list of packages according to their maintainer (or co-maintainer).

  • a better integration with P-A-S files.

  • show tail of logs for build failures.

  • ask wb-adm if build.cgi, bymaint.php, fetch.php, info.cgi are still needed/useful. If you do use use/need them, please speak up before they get removed.

  • if you have any other idea, do submit a bugreport.

6 commentaires:

  1. Great stuff!

    Two comments:
    - Please ask maintainers to drop the old link to pkg.cgi.
    - The sorting of logs by version does not follow dpkg version rules. In particular '~' is not sorted less than everything else.

  2. Nice. I especially like the now intuitive way of selecting logs for fixed package and arch, but across versions, or fixed version, but across arch.

    Minor point: On I don’t see if there are multiple logs for a certain combination. That is sometimes important information.

    Another minor suggestion: A compact mode for would be nice, with one column per arch and the value of “Result” with the link in each cell.

    Thanks for your work on the web pages, I am a heavy user and very much appreciated that.

  3. Thanks :)

    About pkg.cgi, I prefer to implement the last missing feature before asking maintainers to drop the old link to it (imho). But, yes, that's something I should take care of.

    The sorting uses the version field from the database, which is not of type "debversion". I can (probably) hack around that in the PHP scripts, but I'll ask wb-adm to fix that in the database instead since the needed functions are implemented, just not used yet. I reported #621472 for this issue.

    Thanks for your comments!

  4. @nomeata: The logs are sorted by version, and then by architecture. If there is more than one log for an architecture and a fixed version, they'll be shown next to each other. So, you'll see two lines with same architecture name. Of course, I can add some colors to make it visually more visible. Is this your point?

    The compact feature for logs seems like a good idea. I'll try to implement it next time.

    Thanks for your suggestions and remarks!

  5. Ok, now I see it... maybe multiple logs for same version/arch should give the arch only once, and then "–" below, just as for the version column, to make that easily spotable? This way, the line with the arch is always the current one, and Failures in lines with – in the arch column are not to worry about.

    That would also indicate that maybe version/arch/status is a more natural ordering of the columns – just a suggestion.

    And have you considered using rowspan instead of – for multiple rows with the same version?

  6. No need to rowspan, when it can be done with an automaton. Does [1] fit your needs? If so, I'll merge it in the live instance.