I'm currently working on a custom build process and have a problem with the understanding of drop folder. The process creates only some reports which we need for further development. We are using TFS/VS 2012.
What I actually need is either a folder on the buildserver where the Reports are going to be saved and accesable from everyone or on each team members local machine a drop folder. In my opinion the first solution should be better but is it possible, since I'm the only one out of my team which has Access to the buildserver.
If I select the UNC path to the drop folder on the buildserver can other People without Access to this Server use the "Open Drop Folder" button? And how do I even copy files to the drop folder? Is it enough to just do CopyDirectory? In the moment it always says: "This build did not produce any Outputs. The drop Location field is empty..."
I would be really glad if someone could help me.
The purpose of the drop folder is to copy the result of the build from the working folder of the agent and somewhere where it will not be changed by a later build. The share can be on the build server or on another server. No matter what you need to control the permissions to that folder so that whomever needs access has it. Otherwise the Open Drop Folder button will not work.
You can enable so that the build results are copied to the drop location upon build completion. This is a bit different whether you use Build vNext or XAML build. Since you are using TFS 2012, I guess that you are using XAML builds. Drop location is specified under the Build Defaults tab of the build definition.
The output folder from your build will be copied so assemblies, test results etc. will be copied to the drop location when enabled. If there is something extra that you want to be included in your drop, then copy it to the output folder or create it there directly.
Related
Over the last several months myself and those on my development team have run across a new issue. When TFS creates a folder or does a 'Get latest' and overwrites any of the files in the folder structure, it changes the folder permissions to 'Read-only'. This causes an issue, an inconvenience really, where when we go to build the project it will tell us that our access to those folders is denied. If we open the folder and un-check 'Read-only' we are then able to proceed with the build and/or publish of the solution.
We have checked with our networking department, this is not a network setting and is not occurring anywhere outside of TFS. This is only occuring when TFS creates the folder.
Is anyone else having this issue? I've been pouring over settings off and on, trying to determine if I can change this setting. I do not want the folder to be read-only when it is generated or updated.
This is by design but your inconvenience is not. In TFS 2012 (with VS2012) Microsoft introduced local workspaces that do not put anything as readonly.
You can go to the settings of your workspace and change it from server to local any time.
You are also making a common mistake in that you have files that change during a build under source control. If you remove those files you will be able to build even with server workspace.
It is bag practice to put files that you generate under source control.
I have a build process that I've defined with a custom build process template, and I'm looking for some advice on how I can solve a problem I've run up against.
The build process (TFS 2012) is used to build the code that drives our load tests, and I have a separate process that needs to reference a specific path within the drop folder so that it is always using the latest version of the load test code. Automated load testing, pretty standard stuff.
However, I'm wondering if there is a way to get the TFS build to overwrite files it finds in the drop folder. Right now I have it set up to drop to a very specific folder, and not put anything that would change in the folder name (no build number, date, etc.). The thought is, this way the automated utilities that rely on those files have a fixed point to look at.
However, when I currently run the build it gives me error TF42064: The build number '<build>' already exists for build definition '<build>'.
Currently I have the build definition set up to only retain the latest build, because this process is specifically for those automated tools. We have other build processes that are fired for debugging/troubleshooting/logging purposes. Is there a way to get the build definition to overwrite the drop folder each time, or will I have to dig into the .XAML template file to have it delete the folder it finds before the build fires?
The way I approached this requirement was to start with the default template and let the build copy to the normal drop location which allows me to keep historical builds in the same way as all other builds.
Once the build has been completed I then copied to a single drop location from the standard drop location by extending the standard build template, the activity was added just before Check-In gated changes.
The steps involved were as follows:
Within SharedResourceScope:
Delete Unified Drop Location
Create Unified Drop Location
Copy Directory (source: BuildDetail.DropLocation)
By default TFS Build creates a new folder, using the unique build name/number, and drops the files there.
If you want to change this behaviour to overwrite files in a known location (instead of creating a new folder each build) you need to modify the build workflow/XAML (as #Oswald mentioned in the comments).
You can read about customizing TFS Builds from the ALM Ranger Build Guidance on CodePlex: http://vsarbuildguide.codeplex.com/
We had a Project in our solution called DatabaseCreation - which was responsible for creating the database and running the scripts (contained in directories within the project).
Everything was fine.
We then wanted to make the creation of this database to be available from an app and from a console, so re-factored so that we had ...
DatabaseCreation.Core
DatabaseCreation.App
DatabaseCreation.Console
Core has the directories containing scripts, and the App and Console run them.
When built with Visual Studio the directories containing the scripts are copied to the Output bin directory (either App or Console) but problem is: when the build server runs, the script directories don't get copied to the bin folder.
We've tried with TFS and Team City. I realise I could just copy them over, but its frustrating that it works when building in Visual Studio!
Can anyone put me on the right track please?
Check the Build Type for the files in the scripts directory. Find that by clicking one or many files (ctrl+click) then hitting properties (often f4). You likely want them to be content with Copy Always or Copy if newer.
The files were set to copy always, but the build just wouldn't pick them up.
The slightly awkward work around was to add the files as links from one project to another.
Add Existing -> navigate to other project - Looking for the little arrow on the right of the add button -> press that, Add as link option appears.
In a customer project, I need to copy a built dll to another place where it will be checked in and shared amongst different solutions.
I am using a post build step to checkout the target file specifying the /lock:none parameter so that others will be able to create local release builds as well and then copy my new dll file over the old one.
However, when I use tf.exe checkout /lock:none on a console prompt, everything works as expected. When used within a post build script, the file gets locked and nobody can check it out anymore.
How can I solve this?
First question is why do a "checkout" instead of just a "get"? If you're not going to be changing the original file, there's no reason to do a checkout.
To answer the question specifically, though, the reason this is happening is that by default, executable files are set to not allow merging. That means that-- no matter what-- a checkout on a DLL is going to be an exclusive checkout.
To change this behavior, in Visual Studio 2010:
Go to the Team menu
Select Team Project Collection Settings, then
select Source Control File Types
Find Executable Files in the file list, and Edit it to enable File Merging
Click on OK to commit your changes, and you should be good to go.
I have a TFS Build Server where the CI and Release builds occur. The build process runs under some domain account and all the build activity happens under this user's temp directory. Unfortunately, the \Users directory is on the C: drive which turns out to have not much space. Although the build retention policy is quite strict, there are enough builds configured that this space has become quite scarce.
There are other volumes on the machine that have plenty of space.
Can anyone suggest a straightforward way to change the root build directory? I've looked for a TFS property without much success so far.
Thanks.
For TFS 2008 right click on the Builds node and chose "Manage Build Agents". Select the agent of choice and then press "Edit..." and change the working directory. My personal preference is to change it to something like:
c:\bw\$(BuildDefinitionId)
As that will give it a short working folder for your builds (the .NET API's have a 260 character limit for file paths so using as few of those characters as possible for your working folder gives you mor eto play with during your build).
For TFS 2005 edit the TFSBuild.proj file of the relevant build(s) and change the working property to point to where you want it for each build.
Hope that helps,
Martin.
In Team Explorer View,
Right-click Builds -> Manage Build Agents,
Select the build agent and hit 'Edit...'
Set 'Working directory' to
<New Build Root>\$(BuildDefinitionPath)
This works for all projects using that build agent.
My TFS proj files have a property called BuildDirectoryPath
<BuildDirectoryPath>c:\build</BuildDirectoryPath>
This is where all of my source code gets put and where the binaries are built.
Providing an answer for VS2012 / TFS2012 Server.
This will update the working directory on an agent-by-agent basis
- Team Explorer window
- Click Builds
- Click Actions and select Manage Build Controllers
- For each Agent, click Properties and click inside the working directory field and change it, clicking OK when you are done
Note: the OP talked about a domain account and the temp folder. Therefore, this solution may not work for the OP but it did work in my case to move from the System (C) drive to an alternative volume (D in our case).