Teamcity remote run uses previous failing sources

Hello all,

we are trying out teamcity, running on 1 linux server and using 2 linux clients. The projects use maven package as the build statements.

If a user does a remote run where testcases are failing, and someone else does a remote run after that, the second person receives the same errors as the first person with the remote run. It appears as if the remote run does not rollback the changes to the checked out directories. We can skip this error by forcing a clean build for each build but that takes just too much time. My idea was that the remote run is a sandbox and that if your personal changes are failing that other persons will not be effected by this, but that is not how it seems to be working on our side.

I looked around a bit and found the following in the buildAgent.log:
[2009-03-03 13:42:16,689]   INFO - nner2.OsProcessHandlerListener -
[2009-03-03 13:42:17,745]   INFO -    jetbrains.buildServer.AGENT - Personal changes undo process started for build 605
[2009-03-03 13:42:17,747]   INFO -    jetbrains.buildServer.AGENT - Patch applied for build 605
[2009-03-03 13:42:17,748]   INFO -    jetbrains.buildServer.AGENT - Personal changes undo process finished for build 605
[2009-03-03 13:42:17,776]   INFO -    jetbrains.buildServer.AGENT - Publishing artifacts 'teamcity-info.xml' to root artifacts directory
[2009-03-03 13:42:17,776]   INFO -    jetbrains.buildServer.AGENT - Artifacts path teamcity-info.xml not found
[2009-03-03 13:42:17,776]   INFO -    jetbrains.buildServer.AGENT - Done publishing artifacts teamcity-info.xml, total files published: 0
[2009-03-03 13:42:17,777]   INFO -    jetbrains.buildServer.AGENT - Build finished: 605
[2009-03-03 13:42:21,913]   INFO - t.impl.directories.FileRemover - Deleting files from /root/buildAgent/temp/.old...
[2009-03-03 13:42:38,366]   INFO -    jetbrains.buildServer.AGENT -

The build 605 was the personal build with the failing testcases in it, so it looks like the undo process has been started, but yet, the next person receives the same errors.

What have I missed?


Comment actions Permalink

The problem could be caused by old classes. It is a good practice to remove compiled classes as the very first step of the build.

Comment actions Permalink

So instead of using the option "Clean all files" which will enforce a re-checkout of all files, I could try with the maven settings and add clean as parameter?

I will give it a try, thx for the answer so far.



Please sign in to leave a comment.