Actually I didn’t think it was possible to break the build on the build server if one is using Teamcity’s Remote Run feature with automated commit. But it is. Of course, it isn’t actually the fault of TeamCity…
That’s what I did.
The project I am working on still uses CVS. Not the state of the art repository anymore, but that’s how it is. And the special situation is, that I am working remote, meaning we have to go over a VPN connection for CVS access. Also meaning that certain CVS operations done on the whole project sometimes fail due to connection failures. Which was the case when I was trying to create a branch. The CVS operation hanged and I cancelled it. What I didn’t realise was, that some of the files actually were switched to the branched and added there.
So some time later, I started a Remote Run on our build server and everything went fine. Relying on the auto commit, I was pretty astonished, when the next build actually failed. That could not possible be, couldn’t it? But it could - because some of the new files which needed to be committed were added on this crippled branch and never made it on the HEAD. Which of course lead to the fact, that the project couldn’t even compile. Took me a while to find the reason, but alas.
Later the same day, my coworker experienced something similar, but this time the build failed after a successful Remote Run because a file should have been deleted but couldn’t because in the meantime somebody else made some changes on this to be deleted file. And because the file locally was deleted, the update executed before the Remote Run didn’t lead to a local conflict, but prevented IDEA from checking in. (The solution for this problem actually was to re-add the locally deleted file, get the clean copy of it and delete it again).
Conclusion: Even good tools don’t prevent you from breaking the build. Pity!
