Every once in awhile I hit a (technical) wall, stumble upon a great tool or look for a reason to increase my English.
This is my place to share, welcome to my logs.
Recently I've been migrating the old XAML Build Definitions to the new TFS vNext Build Definitions. This was a fairly straightforward process but it still took some time because of all the customizations in our current build process. None the less I really recommend migrating your old XAML definitions to the new vNext Build Definitions.
To be honest, you have to look at your own development/product process and needs. I find it important to future proof this process. For I believe Microsoft vNext (or VSO) is the next step, in the end XAML Build Definitions will no longer be supported (opinion).
Okay, the Pros
- Future proof;
- Support for NodeJS / NPM (and ultimately, WebPack);
- Support for custom/own Plugins and Extensions or from the Visual Studio Marketplace;
- Definitions and dependencies in the Cloud (no longer living in a .dll of GAC).
- Time, it takes some time to get to know the new vNext Build system;
- Convert Custom XAML Buildsteps to new vNext steps (I've done this using free extensions from the Marketplace)
After migrating the old profiles to vNext I started to notice that the used space on my C:\ drive started to grow. When analyzing I found out that all vNext Builds where initially built and stored in "C:\TfsData".
All my previous XAML builds were stored under a different (and desired) drive (E:\). vNext Build Agent ignores the Working Directory which was set in the Team Foundation Server Administration Console.
After some research I found out that the default vNext Build Agent uses a default Working Directory (which, in my case is C:\TfsData). To change this you can follow the steps below. (When writing this Log, we were on TFS 2015 Update 3)
Open up TFS in your favorite browser and navigate to the
Control panel by clicking on the settings gear icon in the top right corner. Make sure your on the 'root' level by clicking
Control panel on this page again.
Download agentbutton (top left).
The file Agent.zip will be downloaded to disk, after the download unzip it to your desired location (in my case: C:\tmp\agent).
After unzipping go to the folder and start Windows Command Line (CMD) in Administrator mode.
Run: ConfigureAgent.cmd and follow the steps below.
Enter the name for this agent:If you wish to overwrite a current Build Agent enter the exact same name. Otherwise create a new Agent by specifying an alternative name.
URL for the Team Foundation Server:In my case: http://my.server.url:8080/tfs
Configure this agent against which agent pool:In my case the
defaultpool was fine.
Enter the path of the work folder for this agent:In my case I wanted to change the path from 'C:\TfsData' to E:\Tfsdata
Would you like to install the agent as a Windows Service:In my case Y(es).
Enter the name of the user account to use for this service:Enter your desired user (needs sufficient permissions).
Enter the password for user account:The password (you won't see the input, but man you are giving input!)
Done, problem solved (in step 4). The new Build Agent is online, just visit the
Agent Pools page again.
Earlier on I mentioned we use both Build Definition types, vNext and XAML. I wanted to make sure that my new vNext Builds would only use my newly created vNext Agent. This can be done by adding Capabilities to a Build Agent and adding Demands to a vNext Build Definition.
Here is how:
Adding a Capability to a Build Agent
Again, navigate to the
Agent Pools tab and select your newly created or modified Build Agent.
Capabilitiestab of the selected Build Agent.
User Capabilities, add a new one. In my case 'vnext' with the value of '1'.
Adding a Demand to a Build Definition
Navigate to your vNext Build Definition and edit the definition.
Demandsfor this build. Add one by clicking
vnextfor the Name and for Type I choose
existsbut you can also specify the exact value.
After the Build is completed there should be 2 results:
1. The Build Output should be stored in the location of your choosing.
2. The Build used the desired Build Agent which for fills the Demands which are specified in the Build Definition.
As always, feel free to comment or contact me!