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.
Related
I am testing automated releases on TFS 2017.
My release definition currently has one environment. A release was triggered once every day, so by the time I can see a number of releases. For every release I can see the outcome for the environment (Succeeded, Partially Succeeded or Failed).
But the test results are kept only for the latest release as it seems. If I open an older release and go to "Tests", it says "No test results are available. To run automated tests, add Test tasks to your release definition".
Only if I open the latest release, I can see all the tests with their individual results.
In the settings of TFS under Test, "Days to keep automated test runs, results, and attachments" is set to "Never delete".
If I edit my release definition and go to Retention, "Days to retain a release" is set to 60 and the minimum releases to keep is set to 3. "Retain build" is NOT checked.
Is "Retain build" the reason why I loose individual test results of older releases?
Or should I mark a release to "Retain indefinitely" to also keep the test results?
What is the best way if I want to keep individual test results for a release?
Based on your description, please check if the tests are executed in release.
Generally we can get the test result with the test run ID (Get a test result). So, just refer to the release logs to check if there are any test runs. You can also check that with REST API: Get task log. If no test runs there, that means no tests were executed.
To keep the test results in releases, just make sure your retention policies (Test, build and release) do not delete the needed builds/release with the test results.
If you select Automated test results in your build retention policy, then the test runs, results and attachments will also be deleted when a build is deleted.
So, if the the build linked to a release has its own retention policy, which may be shorter than that of the release. If you want to retain the build for the same period as the release, set the Retain build checkbox for the appropriate environments. This overrides the retention policy for the build. See Build and release retention policies for details.
In your scenario, if you can see the test runs in logs, then just try to uncheck the option Automated test results in build retention policy and keep "Retain build" checked, then try that again.
We moved to TFS 2017 (from TFS 2013 XAML builds) and the new build & release, but we mainly do windows apps. Q&A and some people are complaining about some functionality missing, for example, there is no way to specify to Keep All builds. I find it extremely strange this would not be possible. How can we do this?
I also looked into the Release part of it, but I don't see anything for Windows app. Besides, it seems that cannot keep releases indefinitely either...?
XAML and vNext are totally two different build system. The behavior is different for the new build system, there is no keep all option. You definitely couldn't use the old retention policy on XAML build for vNext.
If I mark a build or a release to be retained indefinitely, does the retention policy still apply?
No. Neither the definition's retention policy nor the maximum limits
set by the administrator are applied when you mark an individual build
or release to be retained indefinitely. It will remain until you stop
retaining it indefinitely.
More detail about the policy please refer this tutorial: Build and release retention policies
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.
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.
When reviewing the Build History via the browser (servername:8080/tfs/DefaultCollection/MyProj/_Build), I find that there are numerous missing entries for builds which were triggered via gated checkins. When I filter on only that build definition, I find a handful of entries, compared to hundreds of code checkins.
All developers are required to use the gated builds, and all checkins show the telltale signs of success (NO_CI)
Using the API, I find the identical results, which is the root problem...
What would cause this behavior?
check the Retention Policy set on your build definition. By default only the most recent 10 builds will be kept.