My TFS 2017 agent service seems to want to create new work folders randomly: c:\agent_work\1,c:\agent_work\2,c:\agent_work\3,c:\agent_work\4 All the way up to 14 now. What is going on?
Each new build definition gets its own work folder - which is quite sensible actually :-)
Related
HELP!!
I'm learning on the fly here with no training whatsoever! I'm a system administrator who is responsible for supporting the developers. They use Visual Studio, TFS, Plastic SCM and TeamCity amongst other tools.
My task was to get TFS 2015 and SQL Server 2014 installed on a new VM. This I have done but my biggest task now is setting up TFS which seems complicated.
For your information, The developers use TFS 2012 as a Kanban board.
Can anyone point me in the right direction to documentation that simply explains how to copy a project from one collection to another? I'm reluctant to move the project to the new version of TFS without testing the current project.
Thanks in advance.
You cannot copy a single project, there is the TFS integration platform, but it sucks and doesn't officially support TFS 2015
I would say your best bet is to follow the following steps.
In TFS 2012, detach the collection using the TFS Admin Console.
Backup the collection database in SQL server
Copy the backup to the new SQL server
Restore the Database
In the TFS Admin Console in TFS 2015, attach the collection
Wait for TFS to update the Database Schema.
You should now have the full team project collection available in the new server.
I recently updated my TFS 2015 to TFS 2015 with Update 2. Everything went well but i wasn't able to queue builds anymore.
I logged in on the server and realized that I couldn't find my build controller anywhere (Still using XAML Build definitions).
The only thing i saw was this :
In my VS i saw this:
Is the build controller / agent completly gone from TFS with update 2? Did i miss something in the release notes?
Any way to repair my situation?
We have upgraded our TFS from 2010 to 2013, and the same time moved the TFS and databases to new servers, with new names.
One of the very few annoying effects (Probably due to moving the TFS to a server with a new name) is that the build controller/agent from the old server is still visible in lists of available build controllers/agents, but is not visible in the admin gui for build configurations and therefore not possible to remove.
Does anyone have had the same experience and furthermore have a solution of how to remove the traces of old (and not used/wanted) build controllers/agents?
Kind regards,
J
Ok.
Sorry, I found the solution myself now after continue searching and yet again scanning through the microsofts documentation! :)
It's possible to disable and delete controllers and agents through the Manage Build Controllers in Visual Studio.
Also described here: http://msdn.microsoft.com/en-us/library/ee330987.aspx
Just make sure there is no builds in progress, but that's ofcourse also possible to handle through Manage Queues in Visual Studio.
I was setting up a new build definition today and noticed there is an option 'Copy build output to the following Source Control folder'. I don't believe I have seen this before. It appears to me from searching google that it might be new as of TFS 11 (AKA TFS 2012) which I do not have installed on my system (or any system in my company network to my knowledge). My company uses TFS 2010 right now.
I went to another user who is able to view build definitions and it also was present when the build definitions were viewed.
This is what i see:
My questions:
1) Was this a part of TFS 2010 and I am just not remembering seeing it?
2) If this IS part of TFS 2010, how to enable this option (it is disabled).
3) If this is NOT a part of TFS 2010, how did it get there?
Yes, it is part of TFS 2010, but I have no idea how it got here!
I believe this is for those who use TFS 'as a service' (when you
have no file share to copy it to). According to
how-can-i-copy-build-output-to-the-source-control-folder
I have this in TFS/VS 2010 (SP1):
I have the following TFS upgrade scenario: I'd like to change my current TFS 2010 environment to TFS 2012 - this by moving the 2010 server to a new machine with another computer name.
Therefore I simply use the backups of the TFS 2010 databases from the old server and restore them on the new server. Before starting the backup I will turn off several TFS specific services on the old machine to avoid check-ins from devs. In the meantime the developers are working in offline mode. Afterwards I'm going to upgrade the databases.
Now it's getting interesting: The TFS 2012 is up and running with the upgraded project collections and everything works smoothly, but what happens to the local workspaces which are linked to the old TFS url? Is it possible that the developers can switch their exisiting workspaces with their pending changes to the new TFS 2012 url?
If yes, how can I do that? I've already did a test installation and upgraded to 2012 successfully, but I can't find out how to bind my existing workspaces with my pending changes to the new TFS. Initially I thought that the "Change Source Control" dialog could do the trick, but everything I'm able to click in the toolbar are the "Bind/Unbind" and "Refresh" buttons...
If no, I guess I have 2 options:
All I can do is forcing everyone to check-in/shelve and create a new mapping for the new server
OR
simply keeping the old TFS name/url? (Are the pending changes still available in this case?)
Thank you in advance!
P
Workspaces are stored on the server, so when the users add the new server they should find their old workspace already setup for them. Complete with all their existing checkouts etc.
If this doesn't work for a user, they can map a new workspace to the same directory, checkout all files in the tree, then use the tfs power tools do to a uncheckout unchanged (tpft uu /noget) to only leave their changed files checked out.