Automatically build pull requests

[adamralph]

The easiest way to do this is by using https://travis-ci.org which has this built in. We'd need to be building for Mono since their build environment currently only consists of Linux machines. I think it would also be easiest if we used Rake.

This can also be done on TeamCity, see http://hadihariri.com/2013/02/06/automatically-building-pull-requests-from-github-with-teamcity/

For now, let's go with TeamCity. We can think about using Travis CI later if we either start to build for Mono or if Travis CI starts to provide Windows builds.

[adamralph]

No need to be alarmed by all the current build failures. The build configs have now been changed to pick up all branches and pull requests and they picked up all the old ones and tried to run concurrently. I've throttled each build config down to 1 simultaneous build and I'm now going through the 'pending' changes and letting TC build from history. It will take a while to catch up but everything should be green a little later which needs to be.

[adamralph]

FYI I initially set up the pull request builds with a display pattern of pull/*/head pull/*/merge but this was too long and was being truncated in the TC UI. I've since changed it to */head and */merge.

Unfortunately TC still sees them as two different things so some PR's have two lines in the display. However, as these PR's age, they will gradually fall away from the display as TC will deem them to be 'inactive'.

[adamralph]

I decided to switch off the building of the head of the pull request. The problem here was that if the building of the PR head was successful, the 'Report change status to GitHub' build feature would mark the PR as safe to merge which clearly may not be the case.

So now we are only building the PR merge, which is the branch that GitHub creates when does a test merge of the PR to determine whether or not it can mark the PR as being able to automatically merge. Ultimately this is what we want as an indicator as to whether the PR can be safely merged as well.

Also, I had to turn off the 'Report change status to GitHub' build feature for now because the 3 different build configs interfere with each other, i.e. the build might pass on one config and fail on another and then it's a case of most recent wins with the status update on the pull request. We should be able to switch this build feature back on as part of #2 - I've updated that issue to reflect this. Until then, we will have to navigate to the build server to see the outcome of the PR build before merging.

[adamralph]

Marvel at the wonderful output ;-) http://teamcity.codebetter.com/project.html?projectId=project152