When you create a new build definition the Retention Policy is set to "Keep 10 Latest" for Failed, Partially Succeeded and Succeeded builds. Is there a way to change to change those default values globally? We have around 80 builds. Keeping all those builds stored take a ton of space. I'd like to keep only the last two or so.
Use the Community TFS Build Manager for massive edit.
Retention Policies are stored on each Build Definition. So, unfortunately, you cannot change the retention policies for a set of existing build definitions. However, you can make it easier when creating new ones by cloning existing ones. Right-click on an existing build definition and click Clone Build Definition.
Related
In TFS 2010/2015, the Xaml builds can be configured to only ever keep the last x builds (e.g. keep the last 5 builds).
However, the new style builds in 2015 change how this works, to keep builds for x number of days, and keep a minimum of y.
This might work well when dealing with small projects, but the output of our build is >5GB a time.
Is there a way to use the old retention policy, or alternatively have TFS manually delete the old builds as new ones are created?
XAML and vNext are totally two different build system. You definitely couldn't use the old retention policy on XAML build for vNext.
And there is also not any option to make TFS delete the old builds as new ones are created. Retention policies is the only way used to configure how long builds and releases are to be retained by the system for now.
As a workaround, you could use TFS API to do this. You could run a utility to clean the build artifact drop location for builds. Here is a sample from skundu's answer in this question: TFS 2015 - Delete Build Artifacts for your reference.
Our builds generally have a mish mash of work items and commits associated with them and I cannot tell how TFS determines what to add. We are using TFS 2015 update 3 and TFVC.
When a build runs, it gets code from a location somewhere in the branching and folder of TFVC. Typically, something like "root\dev\src\component name" in this way we avoid getting all of the code in our repository and we have CI set up to run so that any changes in this folder will result in a CI build running.
We also run daily builds which run more tests and create a release package that is used by TFS Release Management. I would expect that any changes to code inside of the folder defined in setting up the repository for this build to be included in the associated change-sets of a build. I also expect that any changes checked-in outside of these branches would not be associated. But this is not the case. We see commits from across the entire project.
Does anyone know how this is supposed to work?
I am not sure if this should go in the question or the answer but I have found some additional information, thanks to the hints provided in the answers below.
It appears that the source settings will take the common root between mapped folders of the repository settings, so if I have 2 folders $/Relo/Dev/B1/src/Claims.Services and $/Relo/Dev/B1/src/PSScripts it will take the common root $/Relo/Dev/B1/src as the source settings and include any changes from that folder down within the build. Can anyone confirm this? Of course thats not what I want to have happen. In the History tab of the build definition if I looked at the diff I can see a field "defaultBranch" in the json which seems to be the value that controls this, is there any way to update this field directly?
TFS determines what changesets should be mapped to a build based on the Source Repository Mappings (Build vNext) in the build definition and the last successful build.
So, you will see a list of the changesets with files committed in the lowest common base of any of the mapped folders including all their descendents, since the latest successful build. Whenever you get a successful build (I hope that it happens more often than failing ones ;-)) the list will shorten and only show the last check-in.
Example mappings below will result in any changeset made to anything below $/Relo/Dev/B1/src (because it is the lowest common base):
$/Relo/Dev/B1/src/Claims.Services
$/Relo/Dev/B1/src/PSScripts
Similar it will pick up all the related work items to the above changesets.
This is what should happen. If you see something else, I would have a closer look at the Repository Mappings or Source Settings of the build definition.
#Noel - I guess you are using vNext build and not XAML builds. Or are you using a mix of XAML and vNext?
In general a scheduled TFS build will associate all changes which were not associated in the last successful run of the same build.
I suggest you check once again if the source folder locations are the same for CI build and Daily build?
We are using Tfs2015.Update2.1 [14.95.25229.0].
We have vNext build definitions with a retention policy of 21 days. The maximum retention policy is set to 90 days. Yet we have builds that are over 100+ days old that have not been deleted (they still show up in the list of completed builds). It appears that the retention policy is not being applied at all. What can I do to verify that the retention policy cleanup process is actually running?
If you specify build retention policies, retention policies will delete the items below:
The build record
Logs
Published artifacts
Automated test results
Published artifacts
Published symbols
First please make sure you have set Delete build record = true.
Also note completed builds may be exempted from their associated retention policy in the view of builds by selecting Retain Indefinitely from their context menu. The Release Manager will set the builds as //kmm, please refer to the information in this User Voice.
Please view this build definition’s builds in Build Explorer window, check if some builds be set as Retain Indefinitely in there.
You can also double check the older build recoder to see whether has been deleted. The deleted build record should be the same as below picture:
There was an issue with the background job responsible for retention. Team Foundation 2017 Update 3.1 includes the fix.
We use TFS source control and have two build controllers (one VS2010 the other VS2012). We use the default build workflow template bar a few custom changes.
As we have many branches, how would we go about changing the workspace based on the desired branch?
I was thinking of adding a parameter for the branch ($\oursourcecontrol\branches\main) and then just passing it as a variable in to the get workspace part of the workflow.
Or is there a better way of doing it?
You currently can't and it is really a shame. It would completely break the Trigger support for CI and Gates checkins. You can use the TFS Community Build Manager to quickly clone and adjust build definitions to support multiple branches though.
What you could do, is to fetch more than you need (say $/Sourcecontrol/Branches/*) and then use a string-replace on any path parameter (like solutions to build, test settings file etc) to point them all to the correct solution. You'll probably need to do some templating like {BRANCH} so that you can easily replace these tokens.
The Git build template does support this on a Git repository, but you'd need TFS 2013 to make use of server side Git support.
I mapped the server path in the Repository tab at higher level that TFS branches are contained. Cloak rest of the branches not required for Get sources step except the branch to be built. And create variable to pass the branch name, check allow at queue time. Use this branch variable in build steps to make the build definition work for all the branches. You may need more than one variable based on your branches structure in TFS.
Does TFS offer a way to save, track, and later redeploy builds by build number, or can you only deploy .dlls compiled from the current codebase? I'm looking for functionality similar to what you find in Changeman DS.
Yes. Every build definition in Team Build has a "retention policy" that defines how many historical builds should be kept, depending on certain criteria. You can also mark individual builds as "keep indefinitely." Kind of like a Tivo...
Example walkthru with screenshots: http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
If you need to recover a build that has already been deleted from the drop share, you can do that too -- you'll just have to rebuild it. Simply queue up the build definition, but before you hit Go, type /p:GetVersion="XXX" in the text area at the bottom labeled "additional MSBuild arguments." XXX can be any versionspec, just like you'd use at the tf.exe command line. Examples might be "C12345" or "D1/10/2010" or "LsomeLabel".