Re: Patchwork + automated checking and testing of patches

[Ludovic Courtès]

Hello!

Christopher Baines <address@hidden> skribis:

> I haven't used Patchwork [1], but it has been tried previously with Guix
> [2][3]. It also seems to be a step forward in terms of taking what's
> sent to the mailing list and organising it.
>
> 1: http://jk.ozlabs.org/projects/patchwork/
> 2: https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00056.html
> 3: https://patchwork.sourceware.org/project/guix/list/
>
> I've now written a very rough package and service for Patchwork [4], and
> managed to setup a instance here [5]. With the help of an email account
> subscribed to both guix-patches and guix-commits, getmail and a couple
> of scripts, it should also collect new patches sent to guix-patches, and
> mark those that have been merged to the master branch as "Accepted" [6].
>
> 4: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33185
> 5: https://patchwork.cbaines.net/
> 6: https://patchwork.cbaines.net/project/guix-patches/list/?state=3

Back when we tried, it had a couple of shortcomings:

  1. It would not automatically detect which patches have been merged;

  2. It would not present patch series correctly.

>From what you write it looks like #1 has been fixed, but the web
interface suggests that #2 isn’t quite fixed yet, is that correct?

> I don't intend to do anything with Jenkins, as I think that wouldn't be
> maintainable, but I think setting up some system to check some of the
> following would be beneficial:
>
>  - If a patch series applies to master
>  - If ./configure and make run successfully
>  - If building a guix package with the patch applied works
>  - If running guix lint for all the new/changed packages works
>  - If building all the new/changed packages works
>  - If running the tests and system tests works

I think these are all things we’d love to see.

Apart from item #1, the rest is pretty much Guix-specific.  My
suggestion would be to write tooling piecemeal: for example, things that
allow us to determine the set of packages added or upgraded by a patch
(we actually have a bit of that with ‘guix pull’ and (guix inferior)),
things to apply patches, etc.

We don’t want to reimplement Patchwork, GitLab, etc. so anything that
can be borrowed from there is welcome.

What might be nice is integration with Cuirass: if it had an HTTP API to
easily request a branch build, we could easily hook into it; and then,
we can extended its existing HTTP API as we see fit to make it easy to
retrieve info about build statuses and so on.

All this is easier said than done, but my point is that we should try
and identify easily doable bits so we can incrementally build such a
tool.

Thanks!

Ludo’.