March update on qa.guix.gnu.org

March update on qa.guix.gnu.org

[Christopher Baines]

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

Hey,

I think it's been quite a while since sending out an update on QA stuff
that I'm working on, the last update to guix-devel looks to be back in
December [1].

1: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00093.html

Since then quite a lot of stuff has happened, including meeting people
in Brussels again which was great.

# Infra stuff

There's now a proper system service [2] for the qa-frontpage running on
bayfront.

2: https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=8c17ac564447aa5448fc6eca40001c5b68c17d61

The Git repository is now on Savannah [3] allowing other committers to
push changes.

3: https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/

I've also spent some time fixing and improving the data.qa.guix.gnu.org
upkeep stuff, as it needs to regularly clear out the unused data.

At some point in the near future, I'd like to not be solely responsible
for the financial and administrative part of keeping
data.qa.guix.gnu.org (plus Patchwork and Gitolite) running. There's a
thread about this on the guix-sysadmin mailing list, but if anyone has
any thoughts, please let me know.

# Data service

The data service provides much of the data to make qa.guix.gnu.org work,
and I've been trying to improve it in a few areas recently.

I've added something [4] in which seems to make computing the system
test derivations happen faster. I'm not quite sure of the impact, but
the main benefit at the moment is that revisions are being processed
more quickly, which reduces the time to give feedback on patches and
branches.

4: https://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=bf41c6ebb1c12ec15ee77e727a1ae0d7a1466aef

I've also done another deep dive in to PostgreSQL query performance to
get the blocking-builds page working. This page still needs a bit more
work, as I'm unsure about some of the data it's giving back, and
currently it's difficult to see what builds are blocked and why, but I'm
hoping that this'll be helpful when it comes to branches like
core-updates. Here's the page for armhf-linux builds for a recent
core-updates revision [5].

5: https://data.qa.guix.gnu.org/revision/62ff0b90864c8a4484aa2f14856ff33d05e00b0c/blocking-builds?system=armhf-linux&target=none&limit_results=50

One issue I made surprisingly fast progress on after the Guix Days was
the interaction of grafting and the channel instance derivations,
there's a patch series needing a second round of review here
[6]. Currently data.qa.guix.gnu.org often can't compute the channel
instances for all systems, and these changes should resolve that.

6: https://issues.guix.gnu.org/61363

# QA Frontpage

I've made various small changes to try and make things faster and take
less memory. The memory usage is still an issue, but things like the
branch pages now work which is good.

Substitute availability information is also now shown on the pages for
branches.

# Next steps

Since starting to build core-updates and increasing the number of patch
series tested (both in terms of number and increasing the build limit),
the bordeaux build farm has been running flat out. That's good, but it's
now even more important to tune how builds are prioritised to try and
make better use of the build resources. I think the missing data to do
that is some good picture of what's recently been built, currently being
built, and queued up. This information is in the build coordinator, so
it just needs exposing somewhere so people can easily see it.

Another key area for improvement is trying to make any feedback given
clearer and more actionable. For example, currently for patches and
branches, more failing builds for a particular system will be
highlighted, but there's no easy way of just seeing the things that were
failing to build that weren't before.

It would be good to know what other people submitting or reviewing
patches would benefit from though, what things would be most helpful?

As always, if you have any comments or questions, just let me know!

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]