July update on qa.guix.gnu.org

July update on qa.guix.gnu.org

[Christopher Baines]

Hey,

It's been a while since I sent out the last update on QA things that
I've been working on, there was a small update back in May [1] and one
before that in March [2].

1: https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00142.html
2: https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00222.html

## Changes since the last update

The QA frontpage processing branches is now automatically handled
through creating issues. This seems to be working really well, both as a
process for making it clear what's going on with which branch, and also
feeding in to the automation and testing.

Old builds for patches and branches are now cancelled. This helps the
bordeaux build farm work on the most relevant builds.

Branch comparisons now are done against the merge base, rather than
master, this just helps give relevant feedback.

There's also a new package changes page which is linked to from the
package changes table on the issue and branch pages. This starts to
address the long standing issue where you can't see what the numbers in
the package changes table relate to.

## Current state

While the software is getting better, the service overall is struggling
a bit and that looks to continue for the short term at least.

The queue is very large at [3]. The branches for lots of patches could
have been rebased due to the tex-team-next merge, although it's possible
that the missing i686-linux and armhf-linux derivations recently are
causing some patches to be repeatedly rebased. It'll take a few weeks to
get back to a point where there's data on lots of patch series.

3: https://data.qa.guix.gnu.org/jobs/queue

Discussions ongoing about hosting for data.qa.guix.gnu.org going
forward. So far I've been organising and paying for a virtual machine to
run this, but I'd like to stop by the end of the year.

On the bordeaux build farm side, there's been quite a lot of work
recently on growing the available storage for nars. With the recent work
on branches though, I think it's easier to feel the impact of not having
many available machines. While it's possible to just wait longer for
builds to complete, that has it's own disadvantages. harbourfront (one
of the 3 x86_64 machines is going away at the end of August) which will
further reduce the already limited capacity for x86_64-linux and
i686-linux builds.

I'm in the progress of drafting a blog post about the qa-frontpage.

## Next steps

The qa-frontpage still could do with giving clearer and more actionable
feedback. The other big issue on my mind is getting the data service to
process revisions in less time, as that'll help give quicker feedback
and cope better when rebasing large numbers of patch branches. Apart
from that, I'd like to get back to actually using qa.guix.gnu.org to
review patches, that's a little difficult at the moment as data is
available for very view patches.

Also, as mentioned above, more work needs doing on longer term hosting
for some of the services, as well as growing the bordeaux build farm so
that it can keep up with the growing load.

Let me know if you have any questions or comments!

Thanks,

Chris

Re: July update on qa.guix.gnu.org

[Simon Tournier]

Hi Chris,

Thanks for the update, always nice!

On Wed, 26 Jul 2023 at 09:44, Christopher Baines <mail@cbaines.net> wrote:

> The queue is very large at [3].

Some patches trigger a lot of rebuilds.  And the threshold is about 300
or something, I guess.  Would it be possible to mark these items?

For instance, #65636 [1] is marked as ?

    65636	?	[bug#65636] gnu: git: Update to 2.42.0.

when it implies 799 rebuilds.  Somehow, that’s not the same Unknown as
the one not-yet processed.

Would it be possible to mark these items with ’TooMany’ instead of
’Unknown’?  Or whatever term better than TooMany?  And instead of a grey
’?’, maybe a cross grey.

1: https://qa.guix.gnu.org/issue/65636


> I'm in the progress of drafting a blog post about the qa-frontpage.

Thanks for the read! 

https://guix.gnu.org/en/blog/2023/a-new-quality-assurance-tool-for-guix/


Cheers,
simon

> 3: https://data.qa.guix.gnu.org/jobs/queue

Re: July update on qa.guix.gnu.org

[Christopher Baines]

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


Simon Tournier <zimon.toutoune@gmail.com> writes:

> On Wed, 26 Jul 2023 at 09:44, Christopher Baines <mail@cbaines.net> wrote:
>
>> The queue is very large at [3].
>
> Some patches trigger a lot of rebuilds.  And the threshold is about 300
> or something, I guess.  Would it be possible to mark these items?
>
> For instance, #65636 [1] is marked as ?
>
>     65636	?	[bug#65636] gnu: git: Update to 2.42.0.
>
> when it implies 799 rebuilds.  Somehow, that’s not the same Unknown as
> the one not-yet processed.
>
> Would it be possible to mark these items with ’TooMany’ instead of
> ’Unknown’?  Or whatever term better than TooMany?  And instead of a grey
> ’?’, maybe a cross grey.
>
> 1: https://qa.guix.gnu.org/issue/65636

Yep, it would be nice to add more statuses [1] for issues to make more
of the data easily available.

1: https://git.cbaines.net/guix/qa-frontpage/tree/guix-qa-frontpage/issue.scm#n43

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