Build configuration copy possible bug.

Hi,
 
A colleague of mine has encountered a serious problem when copying a build configuration.  He was copying a very simple configuration (one build step that ran a script) from one project into another one.  When looking at the build logs you can see that the two configurations are using the same working folder!  This means that artifacts from one configuration are appearing in the other builds artifact list (and all sorts of other errors could occur).  Has anybody else seen this?  Is there a work around or fix?  This is a block to our progress currently so a swift answer would be greatly appreciated.
 
We are using TeamCity v6.0.1 (build 15816).
 
Cheers,
Andrew
 
PS you may have noticed I generally post questions that occur in my office, hence the multitude of questions.

6 comments
Comment actions Permalink

Do you mean that you had custom checkout directory specified in the original configuration and it then was copied (http://confluence.jetbrains.net/display/TCD6/Build+Checkout+Directory)?
Note that it is not recommended to use custom checkout directory and you should be able to see warning about this on the Version Control Settings page.

0
Comment actions Permalink

No custom directory was used.  To show you what I mean here are build logs from the two different build configurations:

[10:56:25]: Checking for changes
[10:56:26]: Clearing temporary directory: E:\TeamCity\buildAgent\temp\buildTmp
[10:56:26]: Checkout directory: E:\TeamCity\buildAgent\work\a067ea0d9cfeb6f5

and

[17:08:44]: Checking for changes
[17:08:45]: Clearing temporary directory: E:\TeamCity\buildAgent\temp\buildTmp
[17:08:45]: Checkout directory: E:\TeamCity\buildAgent\work\a067ea0d9cfeb6f5


Note that the hash is the same for two different build configurations, does that make it clearer?

Cheers,
Andrew
0
Comment actions Permalink

The hash should be the same, because both configurations use the same version control settings. This is done intentionally, to avoid unnecessary disk space usage. Otherwise each agent would have hundreds of checkout directories for each configuration.
As for artifacts, the normal practice is to clean folders where the build will produce its files as the first step of the build. You can also use Build cleaner build feature (if you are using TC 6.0). In this case there is no need to write cleanup code in your build scripts.

0
Comment actions Permalink

Right, thank you for clearing that up.  I had presumed that build configurations always had their own work folders.  To test this we changed the checkout directory (by extending the path) and that caused the build configurations to use different work folders.  I understand cleaning as a way to get around this but their are a number of reasons why I think this is a bad idea:

1) If for some reason your clean does not clean everything you can publish artifacts from different build configurations with no way of knowing where they came from.
2) You could have left over files from a different build configuration altering your build on TeamCity in a way which would not be reproducible or visible on your own work machine.
3) This behaviour is not obvious and the reason given (to save disk space) in a lot of cases would not be as much of a problem as the issues that could be introduced by shared checkout folders (described above).
4) The shared checkout folders operation depends on the person creating the build configuration understanding exactly what needs to be cleaned up, this implies understanding all the projects using the shared directory.

Is there a way to ensure that all build configurations always have their own unique hashed folders?

Cheers,
Andrew

0
Comment actions Permalink

If you'll have separate checkout dir for each configuration you may face the same problems. Obviously you need some cleanup code, because otherwise you can publish artifacts from the previous build of the same configuration, or you may not clean compiled classes or dll files and this will affect subsequent builds, and so on. So the separate checkout directory won't work too.

The best practice is to have cleanup code in your build scripts which should be called before main part of the build. Note that you should avoid calling cleanup after the build, because the build itself can be killed, cleanup code won't run and the next build will fail. The build itself should produce temporary files in a limited set of folders, so that it would be easier to cleanup them.

Alternatively, as I suggested before, you can add "Build files cleaner" feautre to your build. This build feature will remove all of the files produced by the previous build before the next build starts.

And we think it is very bad idea to have separate checkout directory, because in many cases source code can be quite huge (we have customers with 30Gb of source code and test data), and agents will run out of disk space quite quickly. Also the build duration will increase, because full checkout should be performed for each new build configuration on each agent even if build configuration with same source code has already been built on these agents.

0
Comment actions Permalink

Right, thank you for the clarification.  We will use the Swabra build feature.

0

Please sign in to leave a comment.