A technical note about a program I wrote last year called bors and some of its ancestry. This is excruciatingly boring unless you happen to build software for a living, in which case I recommend taking a minute to read it.
Not rocket scienceedmFebruary 3 2014, 10:10:02 UTC
Thanks for sharing the history, and the example of how the tools work -- I particularly hadn't realised that was the origin of monotone. As you say "don't break the build" is such a simple concept (and one I try hard to maintain manually in any project I work on), but it's often left to social enforcement at best. It's odd that in a 100%-test-coverage and continuous-integration world that the tooling isn't also prioritising an "any trunk revision is a viable release candidate" test-first-then-merge-to-trunk.
It's a shame that Not Rocket Science Rule didn't get a better early start, I sadly still see many cases where it would have save much time later on (possibly with the mandatory writing of non-trivial test cases before new code).
But also fun to run into somebody with time in Redhat's boom era, hats off to you for that - I have a signed copy of Bob Young's autobiography from November 1999, from my early start in open source.
Aegis has a delightful wrinkle on this: each changeset has to not just pass all existing tests, but also come with a new test, independently tracked and associated with the change, that must fail before the change, and pass after it.
I found working within this structure -- enforced and automated -- extremely pleasant, the few times I worked on aegis-managed projects. Wish it had spread more.
And the pull-request support in Travis-CI is so close, and yet so far... it tells you whether the PR passed when merged into master, at the time when the test was run. But if other PRs have been merged since then, then the result may be stale. One could trivially detect this, but who cares, right?
Though, looking at the bors-reviewed commits you linked, I will say that it is kind of nice that Travis goes ahead and tests everything immediately, so when reviewing you can refer to the test results (or skip reviewing things that are actually still broken). Best of both worlds would be to test immediately when the PR is submitted, and then when it passes review, check whether those test results are still valid and re-use them if so; or, if master has moved on, re-run.
(I guess this is probably more interesting for "slowish project that gets lots of PRs from random outsiders" than "fast-moving project under active development by small team".)
No, it's more that we weren't (and still aren't, on that test farm) fully isolating test environments, so "run random code someone opened a PR containing without any review" would be a nice way for a stranger to take over one of the buildslaves.
In 2014 I'd probably start with docker and do container-per-PR on a public cloud, which I think is now all the new CI stuff works.
Comments 9
Ewen
Reply
But also fun to run into somebody with time in Redhat's boom era, hats off to you for that - I have a signed copy of Bob Young's autobiography from November 1999, from my early start in open source.
Reply
I found working within this structure -- enforced and automated -- extremely pleasant, the few times I worked on aegis-managed projects. Wish it had spread more.
Reply
Reply
Reply
Reply
(I guess this is probably more interesting for "slowish project that gets lots of PRs from random outsiders" than "fast-moving project under active development by small team".)
Reply
In 2014 I'd probably start with docker and do container-per-PR on a public cloud, which I think is now all the new CI stuff works.
Reply
Leave a comment