15 lines
4.2 KiB
Plaintext
15 lines
4.2 KiB
Plaintext
|
Abusing CIA for Fun and Profit
|
||
|
|
<p>No, not the Central Intelligence Agency. I refer to <a href="http://cia.vc/">CIA.vc</a>, a nifty free service that monitors commits on open-source repositories in real time and echoes notifications to IRC. And not really abuse, either – rather, I just implemented a way to make it do something <em>else</em> useful. Others might consider doing likewise.</p>
|
||
|
|
<p><span id="more-1880"></span></p>
|
||
|
|
<p>My GPSD project does a lot of fiddly things with packed binary protocols, and is thus more than usually sensitive to platform idiosyncracies – little- vs. big-endianness, word length, that sort of thing. For the same reasons, it’s also prone to trip over toolchain bugs and unusual compiler decisions about char signedness, structure packing, and the like.</p>
|
||
|
|
<p>We have a pretty good regression-test suite, but it has had the limitation that any dev hacking on the code would tend to run regression tests only on the hardware nearest to hand. Which meant, in practice, that the code got washed on i86_64 and am64 pretty frequently, but oddball platforms like sparc64 and older 32-bit machines didn’t get exercised much.</p>
|
||
|
|
<p>Two days ago I decided to fix this.</p>
|
||
|
|
<p>The devutils directory of gpsd now contains two small programs and a file containing a list of remote-test sites. One of the programs, flocktest, is the one a developer will call. It walks through the flock-sites file and uses ssh to remote-execute the second script, flockdriver, on each one. flockdriver updates a slave git repo, bullds, runs the regression tests, and captures an error log. Both are quite small; flocktest is 160 lines of Python, flockdriver is 150 lines of shell.</p>
|
||
|
|
<p>For efficiency, flocktest backgrounds all the remote flockdriver processes as it spawns them, so they run in parallel. This means the total test time is the maximum of the individual ones, not their sum, a big advantage. But it makes getting the results back to the caller a bit of a problem. My original plan was to simply have flockdriver email them all back, but that thought made me increasingly unhappy. I imagined developers, weary of being spammed with long logs full of boring positive results, tuning out. The last thing the world needs is another spambot, even if it’s a well-intentioned one.</p>
|
||
|
|
<p>The obvious way to reduce the lossage seemed to be to turn the successes into one line emails – test passed, you win, kthxbye. Better. Still not happy-making. Using email for these notifications seemed…heavyweight. Creaky. Old-school.</p>
|
||
|
|
<p>And then it hit me. <em>I can make CIA do this!</em></p>
|
||
|
|
<p>See, over the weekend I’d just written a pair of Python and shell CIA hook scripts for GPSD’s git repo. Yes, there were pre-existing ones, but they were dusty and buggy in minor ways and didn’t autoconfigure themselves as cleverly as I though they should. So I decided to do new ones right. You can see the results <a href="http://www.catb.org/esr/ciabot/">here</a>, and they’re going into git’s contrib/ directory next point release (I just missed one yesterday). </p>
|
||
|
|
<p>The point was, the light XML hackery needed to feed CIA commit notifications was fresh in my mind…and I realized that CIA basically doesn’t care about the field contents. From its point of view, “Regression test succeeded” and “Regression test failed” are perfectly reasonable log messages. The commit ID for the revision tested can go in the same display space it would for a commit. </p>
|
||
|
|
<p>A few hours of hacking and testing later, here’s how it works: both regression-test successes and failures get shipped to CIA.vc to be announced on the project IRC channel, but you only get a log mailed to you in case of failure, when you actually want it. Win!</p>
|
||
|
|
<p>The scripts have very little in them that’s GPSD-specific. I might very well spin them out as a mini-project for other projects with similar requirements to use. Because I think, actually, this is in the spirit of what CIA is trying to enable. The point of the service is to have commit activity be part of the conversation on the project’s real-time channels. Test results as they happen are a very natural thing to add to the mix.</p>
|