views:

300

answers:

5

Hi all,

Our software is built on linux and windows platforms. Depending on the preference of the developer a contribution is developed and tested on either platform and then committed to our subversion repository. It then turns out that the contribution doesn't build on the other platform, and a fix has to be made. The fix on the other platform may again break the build on the original platform, and so on.

I'd rather see that a contribution is built (and regression tested) on the other platform as well before being committed. We have a continuous build server (CruiseControl), but that server builds from the repository. I am looking for a solution where the continuous build server builds on the other platform as a pre-commit check and then commits the stuff if the build and test succeed.

Any suggestions?

+1  A: 

It might be easier to have two branches, one where people checkin, and another which they merge their changes into after they have passed continuous integration.

Douglas Leeder
+6  A: 

Teamcity handles pre-tested commit, you may be able to do something with the new build chaining features in 4.0( http://www.jetbrains.com/teamcity/features/newfeatures.html ). Agents are cross platform and can be configured to only run particular bits of the build, so could possibly be configured to only run a subset of tests.

Note that I haven't actually done this :)

+1 for TeamCity's "Pre-tested commit". They've also got a feature called "Personal Build" that is similar to the pre-tested commit without the commit at the end.
Michael Paladino
Michael - "Personal Build" I think is a feature from Zutubi's Pulse.
ShaChris23
I can confirm BuildForge has the feature too.
Loki
A: 

We used a custom build and test rig that could remotely deploy to multiple OSes (and multiple Database products on multiple OSes). This was done as a nightly build with a rule that you fix your bugs the next morning.

No entirely continuous then, but that's potentially a lot of work to do on a pre-commit hook. Especially if your source control repository locks the affected files for the duration of the pre-commit hook execution.

I think there's a difference between a continuous integration test that runs during the day, per-commit, and a system integration test that runs nightly.

fiddlesticks
A: 

Matheiu Godlewski has made a good suggestion at the CruiseControl wiki

If you combine his suggestion with the veto element, I think you should be set.

Steen
A: 

Douglas Leeder suggested an "integration" branch - the nice thing about it is that it's possible to automate. If the tests pass - merge to the 'trunk'.

Some version control systems (e.g. bzr/hg/git) make this easier than others, but it's possible on most.

orip