[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9rProfVf4VGHGX9no3KTa08nL_oYkK8Nv+eknk4ewVMAw@mail.gmail.com>
Date: Wed, 29 Jan 2020 13:15:20 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: WireGuard mailing list <wireguard@...ts.zx2c4.com>,
LKML <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: wireguard ci hooked up to quite a few kernel trees
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
Powered by blists - more mailing lists