Brussels / 4 & 5 February 2017


Mailing List, Meet CI

Combining Patchwork and Jenkins for fun and profit

What does it take to implement continuous integration-style automated testing into a mailing list-driven software project? Not a lot, actually. In this talk, we demonstrate how a simple but easily scaled testing system can be implemented for a such a project through the combination of Patchwork, the web-based patch tracking system, and open source CI tools such as Jenkins.

At FOSDEM 2016, developers working on Patchwork, the web-based patch tracking system, demonstrated some of the ongoing work in Patchwork. This work ranged from UI improvements to new features and APIs but, collectively, it had the goal of enabling automated testing functionality for software projects developed via mailing lists. The Patchwork developers have been busy since then and the application, in widespread use since 2008, recently hit the 2.0 milestone, marking this functionality as complete.

Projects such as the Dataplane Development Kit (DPDK) have quickly adopted the features that 2.0 brings, using them to enable real time, automated testing of patches sent to the mailing list. This automated testing provides a mechanism for developers to not only sidestep the more perfunctory of tasks, such as coding standard checks, but also to test changes in environments that they may not have at their disposal, such as differing hardware or OS configurations. As seen in projects pairing open source code collaboration tools like Gerrit or Rietveld with CI systems such as Jenkins or BuildBot, this continuous testing can provide huge improvements in developer velocity.

In this talk, we demonstrate how to build a basic "checkstyle" testing system through a combination of Patchwork and an off-the-shelf, open source CI system. This system will retrieve patches and dependencies, apply and test them, and report the results back to both Patchwork and a separate mailing list. This configuration demonstrates the best of Patchwork's new features, and can be easily extended to cover far more complex testing scenarios.


Stephen Finucane