Purging historical builds from the Global List [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

What is the best practice to purge unused or old builds from the Global List?

Currently each CI build appends its label to the Builds list. Over time the list gets bloated and occasionally we manually remove the the unused ones from the list.

Answer 1

The TFS global list does get bloated and it does hamper performance. We have the same problem ourselves.

I suggest doing the following:

1. Changing the work item type definitions to include a Allow Existing Values rule for the WIT fields that rely on the global list for a list of builds (e.g. the "Found in Build" field in Bugs).
2. Periodically (manually or scheduled) remove old builds. You may look at each build definition's retention policy. It will be safe to remove the builds that are not to be retained (last 10 per definition, by default). I do suggest automating this and querying the TFS database to be sure which builds are safe to remove.
3. Alternatively, you may look at the build's drop location and parse the directory results (i.e. keep a build that is stored there).

Answer 2

TFS appends those labels to the global list so that work items can be linked to specific builds. In theory you should not be "cleaning up" the list of builds from the global list because you would be leaving any work items which are using those listitems as a value to be in an invalid state.

There are other lists which get bloated over time, like the list of "assign to" users. Anyone who has ever been a valid user for that team project will show up in that list for the same reason as above. If you delete a user it leaves that user's work items in an invalid state. You will get an error when you try to associate changesets with or perform other operations on invalid work items.

There shouldn't really be any performance issues with long lists of items. It gets annoying selecting from a huge list in a drop down... but that's sort of the nature of the TFS beast. It saves all sorts of information so you can pull metrics over time.

Look in the Tfs_Analysis cube or the transactional tables for builds. You will find rows of data for every build you've ever run. (TFS 2008 deleted rows from its transactional tables when you deleted a build... in TFS 2010 the data is retained and an "IsDeleted" flag gets set in the database, so the data stays in there forever)

Answer 3

I don't know how to flush old builds - we also have a useless bloated list including hundreds of deleted builds that make fields like bug "found in" unusable.

However, much of the buildup can be alleviated for CI builds as you may not want/need labels for them. Each build definition can be edited to stop it labelling source control when the build kicks off. (I can't offer full instructions i'm afraid as i'm away from my PC right now)