Simple retention policies not working

Oct 25, 2007 at 9:40 PM
Edited Oct 25, 2007 at 9:41 PM
After getting CI up and running and monitoring it for a while, I added a couple of retention policies to experiment with that side of TFSBuildLab's functionality. The policies have been defined on two of my build types, and are set to simply retain the 3 most recent builds. This isn't working, however, and my application event log is being filled with the following type of exception eight or so times per minute:

10/25/2007 2:29:15 PM BuildManager.HandleCleanup: An exception occured ... System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
at System.Collections.Generic.SortedList`2.GetByIndex(Int32 index)
at System.Collections.Generic.SortedList`2.ValueList.get_Item(Int32 index)
at Callista.BuildLab.Core.Model.RetentionPolicy.EnforceRetentionPolicy(List`1 builds, DeleteBuildDelegate buildDeleteFunction, WriteLogEntryDelegate writeLogFunction)
at Callista.BuildLab.Core.BuildManager.HandleCleanup()

Any ideas?

PS - You guys really need more contextual details in your logged events.
Oct 27, 2007 at 6:47 PM
Jeremy, unfortunately you seem to be hitting alot of problems that we haven't spotted in our production environment. As for contextual info, when you enable tracing there is more context. But I'll go over it once more prior to the next release and add more context info and also include it when dealing with writing to the event log since I saw we have kindof ignored putting it in there as well :) sorry about that.

Now to the issue... It is a silly bug, since we don't use the only clean droplocation feautre ourself it slipped through, again really sorry about that. I'll upload a patched dll so you can start using it.

Oct 29, 2007 at 11:40 PM
I would like to eventually turn off the deletion of only the files at the drop location and nuke the entire build record out of TFS, but as you can easily imagine there are a number of people at my company that are a bit nervous about the idea of the CI service nuking records in TFS until they at least see the basic file retention working well. :)

That said, one of the key decision-makers here is going to be tough to convince as he (QA Manager) wants the full build records to always be available, primarily because he makes use of the Team Build-generated links between builds and work items / changesets.

If you are in a position to sneak in a fix for this configuration it would be greatly appreciated.
Oct 29, 2007 at 11:52 PM
Edited Oct 29, 2007 at 11:52 PM
I've grabbed the dll that you posted, have installed it and restarted the CI service, and have fired up some retention policies. I haven't seen any more Application Log events in the last few minutes, nor have I seen any builds get deleted from the drop location. Since the lack of deleted builds thus far could be for any of many reasons, I'll keep an eye on things and let you know how it all goes.
Oct 30, 2007 at 7:29 AM
Edited Oct 30, 2007 at 7:32 AM
Thanks for being so patient with the issues we are having, I promise that I'll do some more extensive tests on this scenario (as I said before we do not use it ourselfs at present). I'll try to post a fix for this or atleast an explanation before this weekend.

No promises though, since my wife have gone 2 days overtime on her pregnenacy now :) so I might be preoccupied soon... But no worries we'll have you retentions policies working soon.


Ps. How are your retention policies setup?

Oct 30, 2007 at 7:31 PM
Now I have verified the functionality in the retention policies when running in the RetentionPoliciesOnlyCleanupDropLocation mode and it works as it should as far as I can tell.

So what we can do now is a few steps:

  1. I presume that you have performed the actual retention policy administration using the admin client? Since if you have not the problem is that the caches needs refreshing (you can do this either through the admin gui (file menu) or by restarting the service
  2. Check the build events in the admin client, filter on the build type that you have configured and set the event type to delete you will see any deletes being performed successfully here (you will also se any potential execeptions that have been thrown here when trying to perform the delete with context :))
  3. Turn on tracing and watch for messages containing start/stop enforcing retention policies

Nov 22, 2007 at 5:53 AM
Apologies for being away so long. Things have been busy, and TfsBuildLab has been working. ;)