TeamCity cleanup appears to be inconsistent

After receiving a warning with regards to available space on our artifacts drive, I dug a little deaper into the TeamCity cleanup tasks, and discovered the following:

teamcity hidden folder is not cleaned up. Specifically:

  1. .teamcity\.NETCoverage\CoverageReport.xml - cannot see a use for this. Removed the file, restarted my teamcity test server, see no impact in the coverage results or statistics.
    1. Is this file needed? If so, for what? If not, perhaps you can discard after the build completes. Note that for large projects I have seen this > 12MB ... multiplied by the number of builds per day (50+ at times for a single project), multiplied by ... you get the picture.
  2. .teamcity\properties - what are these two files used for? I see no difference between the two. At the same time, removing them and restarting the build server does not appear to have any effect on the contents of the build parameters tab, so I am assuming that these are temporary files that can be discarded after the build completes.
    1. build.start.properties
    2. build.finish.properties


Any ideas as to how to address these issues?We are using 6.5.4 (build 18046), and I have checked the logs and found no errors.


Additionally, I've noted the following:

  1.     dotCover.snapshots are not cleaned up. These are not required by us.
    1. (Addressed this by setting teamcity.agent.dotCover.publishSnapshot configuration option to false for all build configurations - luckily they are template driven since I have over 100 projects and around 230 build configurations. I would suggest that this is disabled by default. Additionally, even if this is enabled it should probably be removed by default when performing cleanup.
  2. Coverage.zip (compressed complete coverage) is removed. I can see why other people might wish to retain it (since it's compressed, it's not too much of a problem for smaller builds), but personally I see no benefit in retaining detailed code coverage results for older, archived builds - statistics should be sufficient.


Comments on this from the community would be welcome.

2 comments
Comment actions Permalink

An additional suggestion: add the option during cleanup to compress build messages older than x days or last successful y builds. We don't want to lose the logs for many of our older builds, but at the same time would like to recover some disk space.

0
Comment actions Permalink

I see exactly the same behaviour with 6.5.6 (build 18130).

What I also see is that for some build configurations, rather than retaining artifacts longer than expected as you described, get rid of them earlier than expected. For example I have a build configuration that has the last 5 builds with artifacts, but the retention policy should be to keep artifacts for at the last 10 succesful builds. The same goes for history (should be 60 but it's only 40). Only a few build configurations behave like this and I have not identified the reason yet.

Alex

0

Please sign in to leave a comment.