TFS 2018 build won't run because it says it can't find an agent with the needed capabilities even though I have an agent setup with all the necessary capabilities.
It was because I was creating a custom capability but didn't save it correctly. All I needed was a capability called Xamarin.Android so I created this custom capability but when I created it, I didn't know I also had to set a value for it before the Save Changes button will become clickable. After I put in a dummy value for Xamarin.Android it let me save changes and then the build worked.
Related
Does anyone know if the feature to tag agents has dissapeared?
I could not find anything related to over the internet.
My idea is to have certain builds use a specific agent. On TFS 2013 I would use tagging, but i no longer see that option.
On the other hand, I see that it is possible to connect a build definition to a certain agent queue.
There is no more agent tags for TFS 2015 or later version. If you want to use a particular build definition and a specific build Agent which used to run the build.
You could add a user Capability to that specific build agent then in the build definition you put that capability as a demand (General tab).
Another way is directly using Agent.Name or Agent.ComputerName demands in build def or when queuing a build. Take a look at this blog: How to send TFS build to a specific agent or server, which also support on TFS2015.
Oren: Is this feature works in TFS15 SP3?
Reply Eric Parvin: Yes, this should work on TFS 2015 to the newest version.
Use demands and capabilities for this. Add a custom capability to the build agent, and then add a matching demand to the build definition.
Demands and capabilities would work, and you could also create a specific queue, with a single available agent in it, and set the queue to your desired build, so you would achieve the same behavior as desired one.
For some reason, my on-premise TFS 2015 (update3) keeps removing the custom made build steps from build definitions when clicked on Edit Build Definition.
I Then need to click 'undo' to restore the removed custom build step.
Does anyone know why TFS is doing this? And also, is there any fix for this weird behaviour?
As it turns out, there was a minor configuration error in the task.json file. The person who made the build task had Deploy as the value of the visibility property, where only Build and/or Release are valid values.
I think this property somehow got mixed up with the category property - which is the build task category tab it belongs to - whereas visibility defines if the task is a valid build task for Build configurations and/or Release configurations.
I have been asked to create a second custom checkin policy for a second project on our TFS server. So both projects reside on the same TFS server in the same collection but are different projects under that collection. I created the second check-in policy just like the first. When I run the VSIX installer the new one installs. Once I run VS 2015 I can see both custom check-in policies under the TOOS/Extensions and Updates. However when I go to TEAM/Team Project Settings/Source Control/Check-in Policy the new one does not show when you click "Add". The existing one is there but not the new one.
Is there an issue with having two custom check-in policies?
First please make sure you have selected the right team project. Since the check-in policy is based on team project- level.
Also remember to registering Custom Policy:
You need to add an entry to the Windows registry so that your policy appears in the Add Check-in Policy dialog box.
Here is an example of the .reg file that registers the policy.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Checkin Policies]
"Devart.ReviewAssistant.TeamFoundation"="c:\\Program Files\\Devart\\ReviewAssistant\\Devart.ReviewAssistant.TeamFoundation.dll"
Note: that you must install the policy assembly on every computer that needs to have a reference the assembly.
Make sure that you provide valid installation instructions for your policy as it will help fellow developers to install it. More detailed info please refer this blog: Creating TFS Custom Check-in Policy
I'm using new tfs 2015 build agent (not XAML one). In XAML it was possible to change working path from $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath) to any.
Is it possible to change path in new agent to disable or lock $(BuldAgentID) ?
To disable generation of random digits like:
c:\Agent\work\1
c:\Agent\work\2
c:\Agent\work\3
etc.
Use the build variables to change the same,
The working directory for this agent. By default $(Agent.RootDirectory)_work.
now you can assign the variable to any location.
Check the Link
I've seen the question related to the error message you get from TFS when a workspace is already mapped. The accepted answer for removing the workspace is alright as a workaround, but it's already getting tedious to run a delete command each time this error occurs.
What do I need to change in order to get out of having to use this workaround? I've got two builds (continuous integration and nightly deploy), and need to add at least one more build type. I followed this URL to see if there was a possible resolution there, but I'm not sure I understand it completely.
I am not sure how this is accomplished in TFS 2010, as I have not gotten to work with Team Build in 2010, yet. In 2008, though, if you expand the Builds node in the Team Project and right-right click on either of the builds, you will see a "Manage Build Agents..." option. Click into that, and it will bring up a dialog. One of the things on that dialog is an option called "Working Directory". Do you have the same hard-coded path in both of them?
By default, when you create a new build definition, it provides a calculated folder for this value. This is where the build agent will do the checkout from TFS for the build attempt. The default value is, $(Temp)\$(BuildDefinitionPath), I believe (I am not connected to TFS at the moment).
The article you link to is basically saying that you should include either that $(BuildDefinitionPath) value or the $(BuildDefinitionID) value as part of that path in that dialog so that the two builds do not try to use the same workspace. Changing the working folder to include one of those values should resolve your issue, going forward.