For the last few years there has been a slow growing improvement to the testing and QA Squid is subject to. This last week has seen the construction and rollout of a full-scale build farm to replace some of our simple internal testing. Robert Collins covers the growth process in his blog.
Here is the initial release notice:
Hi, a few of us dev’s have been working on getting a build-test environment up and running. We’re still doing fine tuning on it but the basic facility is working.
We’d love it if users of squid, both individuals and corporates, would consider contributing a test machine to the buildfarm.
What we’d like is to have enough machines that are available to run test builds, that we can avoid having last-minute scrambles to fix things at releases.
If you have some spare bandwidth and CPU cycles you can easily volunteer.
We don’t need test slaves to be on all the time – if they aren’t on they won’t run tests, but they will when the come on. We’d prefer machines that are always on over some-times on.
We only do test builds on volunteer machines after a ‘master’ job has passed on the main server. This avoids using resources up when something is clearly busted in the main source code.
Each version of squid we test takes about 150MB on disk when idle, and when a test is going on up to twice that (because of the build test scripts).
We currently test:
I suspect we’ll add 2.7 to that list. So I guess we’ll use abut 750MB of disk if a given slave is testing all those versions.
Hudson, our build test software, can balance out the machines though – if we have two identical platforms they will each get some of the builds to test.
So, if your favorite operating system is not currently represented in the build farm, please let us know – drop a mail here or to noc @ squid-cache.org – we’ll be delighted to hear from you, and it will help ensure that squid is building well on your OS!
That just about covers everything. Hardware and build software requirements are listed in the build farm page.