Re: Patchwork + automated checking and testing of patches

[Christopher Baines]

Ludovic Courtès <address@hidden> writes:

> Hello!
>
> Christopher Baines <address@hidden> skribis:
>
>> ...
>>
>> 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].
>>
>> ...
>
> 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?

On the detecting merged patches, that's definately working for some
patches though. I don't fully understand what criteria it's using
though, as it's comparing the commits that come through to the master
branch, and I bet it's possible to confuse it a bit by tweaking patches
before pushing them.

Regarding patch series, I don't know much about the specifics of this,
and I don't know much about Patchwork, but just comparing a few patches
on the older version [1], and the newer version [2], it looks like it's
better. Take this patch [3], it's part of a series, but you can't
tell. However, with this patch [4], you can see the series and related
patches towards the top of the page, and also a link to download the
whole series as an mbox. How does this look to you?

1: https://patchwork.sourceware.org/project/guix/list/
2: https://patchwork.cbaines.net/project/guix-patches/list/
3: https://patchwork.sourceware.org/patch/18558/
4: https://patchwork.cbaines.net/patch/66/

>> 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.

That all matches up well with what I've been thinking about :)

signature.asc
Description: PGP signature