This attachment cleanup tool can be downloaded from the link below.
For some of the customers who use the advanced capabilities of TFS 2010, such as collecting diagnostic data from the Test runs, they come up with the issue of quick build up the TFS Database disk space. Depending on the volume of diagnostic data collected with each build, this can reach critical threshold levels very quickly.
Some of the general advice is as follows:
As it stands now, one has to do some amount of juggling and figuring out, where the right balance is with respect to collecting diagnostic data. There is no real prescriptive solution other than to arrive at the correct balance. The balance is a mixture of factors:
a) Deciding upon the correct set of data to collect.
b) Deciding when to collect. Should collection be part of a daily build? Should it be part of CI build? And so on.
c) Setting a scheduled task to go and cleanup the attachments on a regular basis.
Below I show a sequence to help understand the phenomenon. The following is a screen shot of the tbl_AttachmentContent table prior to invoking a build which contains tests that collect some data. The important data is of course the DataSpace which is 105.664 MB (Note that this is for a minimalistic demo and your specific instance might most probably have the data at another number).
I have created a simple ClasssLibrary and configured a few unit tests for the library.
I also created a build definition which includes the tests I created to be run as part of the build.
In my test settings file, I have turned on some level of collection, though not all of it. Depending on the nature of the application and as well as the anticipated level of data that the team feels that needs collecting, you might select a few OR even all of it (or close). This is where one needs to exercise caution and judgment in collection. Do you need some OR all of it?
After firing this build which also runs the tests, the size of the tbl_attachmentContent has gone up, as you can see below. As you can see the row count has increased to 182 from 167 and as well as the size has increased from 105.664MB to 105.727MB. This is only a small bump in this demo, due to the nature of my sample. But in most cases this bump could easily be a GB and more. It all depends on your test runs and the configuration you have for collecting the data.
Now that the table has been shown to grow, let us proceed to see how to delete the data and reclaim space.
Here is where one would use the Test Attachment Cleanup tool. This tool is by default installed in the folder: C:\Program Files (x86)\Microsoft\Test Attachment Cleaner. This is available for download from: http://visualstudiogallery.msdn.microsoft.com/3d37ce86-05f1-4165-957c-26aaa5ea1010/
To run this tool fire up a command prompt and run it. Prior to this your team needs to carefully consider what you wanted deleted. There are several sample settings file in the “Sample Settings” folder.
For this demo I have adopted to delete all of the attachments that were created later to a particular point in time. That is all of the data created by the Build that ran the tests will be deleted.
Here is my settings file:
Basically any data that was collected after 5/30/2011 will be deleted.
The tool can be run with a preview mode, which will show all of the stuff that will get deleted without actually being deleted.
Here are the contents of the output1.txt which shows what will be deleted.
As you can see for a minimalistic test run I had done, there is so much of data collected. One can easily understand how for an involved test run, the amount of data collected will be quite huge. Make sure to view the preview data and confirm these are the things you want deleted.
Now to actually delete, one has to change the mode to “delete” as follows.
Once deleted, you can view the output file to see what was deleted.
Also going back to the collection database, and seeing the properties of the table, one can see that the size and row count had been reduced.
Running a query off of the tbl_attachmentContent table one can see there are no rows past the deletion criteria date of 2011-5-30 that we had set.
Also there are several other options possible. All of these are dealt with in the various samples settings file available as part of the download.
Finally if you prefer you can also set this to run a regularly scheduled NT Task to run periodically. It is also possible to make it as part of a Build by setting up a custom task in your build workflow.