Build.Preview - Drop Folder not deleted when build is deleted - by Dominic Perreault

Status : 

 


24
0
Sign in
to vote
ID 1513256 Comments
Status Resolved Workarounds
Type Bug Repros 11
Opened 7/6/2015 5:40:01 AM
Access Restriction Public

Description

Hi, 

When using the new Build.Preview feature with my On-Premise TFS 2015 RC, all my drop folders remains on build server disk after build is deleted.
I'm trying to change the build system from XAML builds to Build.Preview script system builds for one of our product.

My setup is:
 - Dedicated build server with an agent installed (not using the default agent onto the TFS Server)
 - This build server is already running XAML build for the same product
 - Both build system (both Windows services) are running using the same identity (same NTFS security is applied)
 - Build Windows services identity is currently server administrator (to make sure this wasn't the problem)
 - Both XAML builds and Build.Preview builds are dropped at the same UNC path (of course not overwritting one each other)
 - Both build definiton's retention policies are set to "delete everything"
 - When i delete a XAML build from Visual Studio IDE or Web Access, drop folder gets deleted
 - When i delete a Build.Preview build from Visual Studio IDE or Web Access, drop folder remains on disk

Expected result was a drop folder deletion while the folder remains!

You can read a discussion about the bug over here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/cda72721-9405-4683-9794-7d8cdc71e733/buildpreview-agent-unable-to-delete-readonly-item-within-staging-folder?forum=tfsgeneral
Sign in to post a comment.
Posted by CKKKitty on 7/20/2017 at 8:43 AM
Will or has this fix also been added to an update for TFS 2015?
Posted by Microsoft on 9/15/2016 at 9:49 AM
This has been fixed on Team Services and is in Team Foundation Server '15', which is currently in prerelease.
Posted by jryutzy on 7/1/2016 at 5:54 AM
Is there any update on this? I have TFS 2015 Update 2.1 and when I delete a completed BUILD it still does not clean up the files on my UNC Drop Location. I have a "Copy and Publish Build Artifacts" task with a path of \\servername\Deployment_Requests\BW.Application\$(Build.DefinitionName)_$(Build.BuildNumber). I even tried fully qualifying servername.domain and it still didn't delete the files that were published to Drop Location. This is really annoying because we have to manually clean up drop location files even after the BUILD is deleted. When manually deleting the build it prompts saying, "Are you sure you want to delete everything about build XYZ including details, FILES AND FOLDER UNDER DROP FOLDER, test results, symbols and label". This implies that it will delete DROP FOLDER files but it does not. I don't see any info in logs either.
Posted by Christian Artin on 5/12/2016 at 1:31 PM
This is also a very critical problem for us. Our builds are huge, so disk space usage stacks up quite fast.
I saw that Bryan also commented here: http://stackoverflow.com/questions/31276466/should-artifacts-associated-with-a-build-record-be-deleted-when-the-build-record

Not sure what he meant by QU2, though. We have TFS 2015 Update 2 and it currently doesn't seem to work.
Symbols and Drop are not deleted when the build is deleted.
Posted by MagnusTim on 4/6/2016 at 5:23 AM
This is a big problem for us as well, do you know when this will be fixed or do you have a recommended workaround except for server drops?
Posted by Michael S Marmack on 3/18/2016 at 7:44 AM
The lack of this feature is a huge issue for us as our build drops share is not being cleaned up and we keep running out of space. its not hard for a single team to put a job in to clean up there area but it is really hard to get a 100 teams to all understand the issue and clean up after themselves. Any idea where this is on the roadmap?
Posted by Dominic Perreault on 7/8/2015 at 3:54 AM
Just wanted to add more information:

- My UNC drop folder path is actually local to the build server (\\BuildServer\Builds\Drops is actually D:\Builds\Drops)
- Is it configured that way within the build definition because developpers are used to get builds from that location, so the build definition uses same path
- Even tried changing the build definition for a drop folder path using D:\Builds\Drops\$(Build.DefinitionName)\$(Build.BuildNumber) and the build still doesn't get deleted. Tried both deletion from Web Access and VS2015 RC
Posted by Dominic Perreault on 7/7/2015 at 8:25 AM
Yes i am refering to a UNC drop folder! To clear things up, you're saying that you stopped deleting the DropFolder when using the Build.Preview system while you we're deleting it using the old XAML build system?

And you backlog now contains a item to bring this feature back?
Posted by Microsoft on 7/7/2015 at 8:18 AM
If you're referring to the staging directory on the build *agent*, then that's intentional since we clean up the staging directory on the next build (not after the build) in case a build hits issues (logs and staging available for investigation).

On retention getting run - we will delete drops in FC (server drops).

If you're referring to drops that get published to UNC shares, then that's true. Currently, we don't clean up UNC shares external to the build system. That's on a backlog so I'm closing as being on our backlog.
Posted by Microsoft on 7/7/2015 at 8:18 AM
If you're referring to the staging directory on the build *agent*, then that's intentional since we clean up the staging directory on the next build (not after the build) in case a build hits issues (logs and staging available for investigation).

On retention getting run - we will delete drops in FC (server drops).

If you're referring to drops that get published to UNC shares, then that's true. Currently, we don't clean up UNC shares external to the build system. That's on a backlog so I'm closing as being on our backlog.