Thanks for your comment. In fact I was preparing a continuation post today which mentions SCP and SSH as a way to do this kind of work, I’ll also mention your suggestions in it. As you will see, I also took a wider look at the whole thing – running distributed CI processes, which I guess is be the opposite of what you’re suggesting (concentrating on just the remote invocation). Well as long as this is just brainstorming (=daydreaming), I guess I’m OK

As for CruiseControl external properties, looks like CCNet also supports them through the configuration preprocessor (http://confluence.public.thoughtworks.org/display/CCNET/Configuration+Preprocessor), but I haven’t used this feature so far. The main problem I have with CCNet is that it doesn’t really do distributed builds – by “really” I mean that, yes, you can set up triggers between projects, but they are in essence treated as separate projects, which makes them harder to monitor and maintain and also makes the whole setup quite brittle. I’ll write more about this in today’s post.

Best regatds, Igor

Now, for your job runner service – I think there’s a good idea behind this, but its scope should be limited. Your description is conflating two problems: deploying builds to a test host, and triggering a remote test.

The file deployment problem is already solved. The remote asynchronous job triggering isn’t, so this project might do well to focus only on the second part, and it would be a really useful tool.

Deployment: Your regular build script already produces a staging directory and a compressed archive. It’s trivial to just rsync the whole staging directory to a testing server, or a central file server, or scp the compressed archive to each test host (Ant, for example, has an optional task useful for this). Your testing server, whatever the OS, could also just mount the build server’s output share into its own filesystem and run from there. Perhaps a cleaner approach is to concentrate this responsibility on the test runner, so there’s no coupling between the build host and the test rigs – I do this by having the test job pull down the latest build whenever it starts up. You mention the annoyance of writing a separate script each time, but it doesn’t have to be that way. It’s quite easy to write a simple generic Ant script that takes in a project name and pulls down the latest build for that project from your deployment server, extracts it locally, and exits. A generic script like this can be used across all your projects and build machines, as long as it’s called with different arguments.

So I think remote triggering jobs (maybe using an XML-RPC request to your new service?) is where the exciting unsolved problems are