wireguard ci hooked up to quite a few kernel trees

wireguard ci hooked up to quite a few kernel trees

[Jason A. Donenfeld]

Hi all,

With the merging of wireguard, I've hooked the project's CI up to
quite a few trees. We now have:

- net-next
- net
- linux-next
- linux (Linus' tree)
- wireguard-linux (my tree)
- wireguard-linux-compat (backports to kernels 3.10 - 5.5)

When the various pushes and pulls click a few more cranks through the
machinery, I'll probably add crypto and cryptodev, and eventually
Greg's stable trees. If anybody has suggestions on other relevant
trees that might help catch bugs as early as possible, I'm all ears.

Right now builds are kicked off for every single commit made to each
one of these trees, on x86_64, i686, aarch64, aarch64_be, arm, armeb,
mips64, mips64el, mips, mipsel, powerpc64le, powerpc, and m68k. For
each of these, a fresh kernel and miniature userland containing the
test suite is built from source, and then booted in qemu.

Even though the CI at the moment is focused on the wireguard test
suite, it has a habit of finding lots of bugs and regressions in other
weird places. For example, linux-next is failing at the moment on a
few archs.

I run this locally every day all day while developing kernel things
too. It's one command to test a full kernel for whatever thing I'm
working on, and this winds up saving a lot of time in development and
lets me debug things with printk in the dumbest ways possible while
still being productive and efficient.

You can view the current build status here:
https://www.wireguard.com/build-status/

This sort of CI is another take on the kernel CI problem; I know a few
organizations are doing similar things. I'd be happy to eventually
expand this into something more general, should there be sufficient
interest -- probably initially on networking stuff -- or it might turn
out that this simply inspires something else that is more general and
robust, which is fine too. Either way, here's my contribution to the
modicum of kernel CI things happening.

Regards,
Jason

Re: wireguard ci hooked up to quite a few kernel trees

[Bhaskar Chowdhury]

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

Looks bloody good Jason! thanks, man!

~Bhaskar

On 13:15 Wed 29 Jan 2020, Jason A. Donenfeld wrote:
>Hi all,
>
>With the merging of wireguard, I've hooked the project's CI up to
>quite a few trees. We now have:
>
>- net-next
>- net
>- linux-next
>- linux (Linus' tree)
>- wireguard-linux (my tree)
>- wireguard-linux-compat (backports to kernels 3.10 - 5.5)
>
>When the various pushes and pulls click a few more cranks through the
>machinery, I'll probably add crypto and cryptodev, and eventually
>Greg's stable trees. If anybody has suggestions on other relevant
>trees that might help catch bugs as early as possible, I'm all ears.
>
>Right now builds are kicked off for every single commit made to each
>one of these trees, on x86_64, i686, aarch64, aarch64_be, arm, armeb,
>mips64, mips64el, mips, mipsel, powerpc64le, powerpc, and m68k. For
>each of these, a fresh kernel and miniature userland containing the
>test suite is built from source, and then booted in qemu.
>
>Even though the CI at the moment is focused on the wireguard test
>suite, it has a habit of finding lots of bugs and regressions in other
>weird places. For example, linux-next is failing at the moment on a
>few archs.
>
>I run this locally every day all day while developing kernel things
>too. It's one command to test a full kernel for whatever thing I'm
>working on, and this winds up saving a lot of time in development and
>lets me debug things with printk in the dumbest ways possible while
>still being productive and efficient.
>
>You can view the current build status here:
>https://www.wireguard.com/build-status/
>
>This sort of CI is another take on the kernel CI problem; I know a few
>organizations are doing similar things. I'd be happy to eventually
>expand this into something more general, should there be sufficient
>interest -- probably initially on networking stuff -- or it might turn
>out that this simply inspires something else that is more general and
>robust, which is fine too. Either way, here's my contribution to the
>modicum of kernel CI things happening.
>
>Regards,
>Jason

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