Currently my team is using local build agents for our on-premise TFS 2015 installation. We've installed these build agents on our own development machines. However we are having issues limiting the space required for the continuous integration builds.
Our disk space is limited. Consequently we have to remove old build tasks (including sources and artifacts) manually to clean-up disk space.
Is there some way to automate this? Preferly by telling TFS to automatically remove older build tasks.
You can specify build retention policies, which will automatically delete old completed builds to minimize clutter. You modify these policies on the Retention tab of your build definition. Retention policies will delete the items below:
The build record
Logs
Published artifacts
Automated test results
Published artifacts
Published symbols
Currentlt, server drops are deleted when a build is deleted but drops to UNC shares are not. This has been fixed on Team Services and is in Team Foundation Server '15', which is currently in prerelease. Check: https://connect.microsoft.com/VisualStudio/feedback/details/1513256/build-preview-drop-folder-not-deleted-when-build-is-deleted
Working folder on your machine won't be deleted . In order to delete UNC drops and working folder, you can add a task Delete files in your build definition to delete working folder and drop folder.
Related
We use the build and release parts of TFS 2017. On the server we can see that there are some folders called r1, r2 etc. In the same folder are also the builds located with a number as folder name.
What is the r folder used for? Can we delete the folders without breaking anything inside TFS? Can we set a retension period for the folders?
Those are folders used when running a release to hold artifacts.
You can delete them, but the next time a release runs on that agent, the data will come back. There's no point in deleting them unless you're never running a particular release again. Think of them as reserved disk space.
According to your description, seems you are talking about C:\agent_work\r1\a & C:\agent_work\r2\a It' called Agent.ReleaseDirectory
The directory to which artifacts are downloaded during deployment of a
release. The directory is cleared before every deployment if it
requires artifacts to be downloaded to the agent. Same as
System.ArtifactsDirectory and System.DefaultWorkingDirectory.
You don't have to manually delete them, as you see above, the directory is cleared automatically if the new deployment requires artifacts to be downloaded to the agent.
More details info about this you could refer Default variables of Release from official MSDN doc.
I'm trying to reduce build times and right now Source Indexing and Symbol Publishing with TFS 2015 takes (~1hr). Maybe indexing sources and publishing symbols is just heavy on disk I/O and bottle-necked there -- I'm unsure. I want sources to continue to be indexed and symbols to continue to be published for this particular build as it makes debugging exponentially easier.
Are there any ways to make source indexing and symbol publishing with TFS 2015 faster?
It's hard to just reduce the time of this task "Source Indexing/Symbol Publishing "
However, there are other ways to reduce the build time：Such as setting clean workspace to none. Changing the workspace setting from recreate a fresh workspace every time to incremental by which it will incrementally download the source to the build workspace only.
During the build process, the build agent compiles and does other work with your source files. Before the build agent can do this work, it downloads the files from folders on your version control server into a local working directory. To facilitate downloading these files, the build agent creates a version control workspace, which maps the folders on the server to the local folders in the working directory for the build agent. If you set clean workspace , it will delete the old files and get down the sources during every triggered build. So set clean workspace to none can reduce the time of the build.
And it's also related to the hardware of your server. Improve the performance of the server will also reduce your build times.
I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.
I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).
It's possible to achieve this with TFS Release Manager 2013.4?
Update 1:
A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.
Update 2:
The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.
Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.
In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command
TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%
to queue the Collector build.
This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.
Now you can use Release Manager as usual on this Collector build.
I am not a developer nor am I the Application Lifecycle Manager. I pull the latest builds from TFS Build Server along with the latest code and I import them in AppScan source for analysis (security tool). Against each security findings there is a class name within which the findings were found along with the directory where the class is located.
Builds are created automatically during a certain time of the day. As mentioned earlier the directory names change every time after a new build and a new number (highlighted below) is introduced. It is not sequential, does anyone know of TFS build server assigns these numbers.
C:\Builds**12**\Development
C:\Builds**14**\Development
C:\Builds**13**\Development
C:\Builds**15**\Development
TFS will create folders based on the following.
DriveLetter\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
so if you have 1 controller with 4 agents on a clean install you would get
Drive:\Builds\1\$(BuildDefinitionPath)
Drive:\Builds\2\$(BuildDefinitionPath)
Drive:\Builds\3\$(BuildDefinitionPath)
Drive:\Builds\4\$(BuildDefinitionPath)
Your Build definition is the name of the build definition and then each subsequent build is stored underneath, with each individual build getting its own folder.
these settings are available on the Build Agent properties screen.
These are transient files and you cant rely on them being there. They are only used as part of the build. You would be better doing a "Get" from TFS at the appropriate Changeset number for the build and using the binaries from the drop folder.
My build agent working directories are starting to take too much space on the disk. I wonder if it is okay for me to delete some old folders, or if I should back them up.
What is the impact of deleting a TFS build agent working directory?
Are the labels affected?
Is the build history affected?
You can do it if your builds are not incremental (incremental get). If your builds always get all source files for every build it is OK to delete working directories. Build history and labels are not affected. Your build logs are in the drop location and it shouldn't be a problem either.
It is a problem for incremental (at least from incremental get) builds. These builds are getting only the latest changes from the TFS source control before every build, not the whole workspace as defined in the build definition's workspace.
Check your build definition's Process → CleanWorkspace settings. If it is set to All, it should not be a problem to delete the build directory.
Assuming I understand your question correctly, make sure you delete the builds through the TFS interface. Don't just delete the folders off the disk if you can help it. The TFS 2010 Build Deletion dialog gives you some options about what to keep and what to delete.
http://blogs.msdn.com/b/jpricket/archive/2009/12/09/tfs-2010-how-about-those-build-delete-options.aspx
You can also set up build retention policies so that old/unused builds automatically get deleted.