[Automated-testing] Structured feeds

Daniel Axtens dja at axtens.net
Thu Nov 7 02:57:19 PST 2019


Dmitry Vyukov <dvyukov at google.com> writes:

> On Wed, Nov 6, 2019 at 9:50 PM Konstantin Ryabitsev
> <konstantin at linuxfoundation.org> wrote:
>>
>> On Thu, Nov 07, 2019 at 02:35:08AM +1100, Daniel Axtens wrote:
>> >This is an non-trivial problem, fwiw. Patchwork's email parser clocks
>> >in
>> >at almost thirteen hundred lines, and that's with the benefit of the
>> >Python standard library. It also regularly gets patched to handle
>> >changes to email systems (e.g. DMARC), changes to git (git request-pull
>> >format changed subtly in 2.14.3), the bizzare ways people send email,
>> >and so on.
>>
>> I'm actually very interested in seeing patchwork switch from being fed
>> mail directly from postfix to using public-inbox repositories as its
>> source of patches. I know it's easy enough to accomplish as-is, by
>> piping things from public-inbox to parsemail.sh, but it would be even
>> more awesome if patchwork learned to work with these repos natively.
>>
>> The way I see it:
>>
>> - site administrator configures upstream public-inbox feeds
>> - a backend process clones these repositories
>>    - if it doesn't find a refs/heads/json, then it does its own parsing
>>      to generate a structured feed with patches/series/trailers/pull
>>      requests, cross-referencing them by series as necessary. Something
>>      like a subset of this, excluding patchwork-specific data:
>>      https://patchwork.kernel.org/api/1.1/patches/11177661/
>>    - if it does find an existing structured feed, it simply uses it (e.g.
>>      it was made available by another patchwork instance)
>
> It's an interesting feature if a patchwork instance would convert and
> export text emails to structured info. Then it can be consumed by CIs
> for precommit testing and other systems without the need to duplicate
> conversion.

This already happens.

Snowpatch does this and uses it to run CI checks on patch series as soon
as they arrive, and sends them back to patchwork as test results. It has
been running on linuxppc-dev for over a year.

Snowpatch is at https://github.com/ruscur/snowpatch

An example patch showing the checks having been run is
https://patchwork.ozlabs.org/patch/1190589/

I think there's a different CI system used for some device-tree patches:
e.g. https://patchwork.ozlabs.org/patch/1190714/ - I have no idea how
this works in the backend, but it also uses the patchwork API.

Regards,
Daniel


More information about the automated-testing mailing list