Team Foundation Server Plugin


This plugin integrates Microsoft Team Foundation Server source control to Hudson.

No longer maintained in the Hudson community

This plugin has moved it's development to the Jenkins infrastructure, which can be found at the new Jenkins Wiki page. Please report issues and find the latest versions in the Jenkins community.

With this plugin you can use a workspace that will create a work folder in the Hudson workspace. At the moment, this plugin supports:

  • Retrieving read-only copies of files and folders from a Team Foundation Server.
  • Polling a Team Foundation Server to automatically start builds when there are changes.
  • Links from the Hudson change sets to Team Server Web Access. (Also known as a repository browser)

The workspace will automatically create a workspace on the Team Foundation Server and map a work folder (in the Hudson workspace) to it.


System configuration

  1. Open the system configuration page "Manage Hudson->Configure system"
  2. Enter the path to the TF command line client, that should be used by Hudson

Job configuration

Server URL The URL to the Team Foundation Server. Example:
Project path The project and path to retrieve from the server. The project path must start with $/, and contain any sub path that exists in the project repository. Example: $/project/trunk/src.
User name The user name to use when connecting to the server. The user name must contain the domain and user name. The user name must be formatted either as domain\username or username@domain.
Password The user password.
Use update If this option is checked, then the workspace and work folder will not be removed at the end of build. This makes the build faster, but artifacts remain between builds. If it is not checked, the plugin will create a workspace and map it to a local folder at the start of the build, and then delete the workspace at the end of the build.
Local work folder The name of the local work folder. The specified folder will contain the files retrieved from the repository. Default is ., ie the files will be downloaded into the Hudson workspace folder.
Workspace name The name of the workspace that Hudson should use when creating and deleting workspaces on the server. The workspace name supports three macros; ${JOB_NAME} is replaced by the job name, ${USER_NAME} is replaced by the user name Hudson is running as and ${NODE_NAME} is replaced by the name of the node. Default workspace name is Hudson-${JOB_NAME}.
Repository browser If the Team Foundation Server has any web access to the files, this can be configured here. By adding a repository browser, the plugin will create links in the Changes page to the repository browser. Currently the plugin supports Team System Web Access.

Build environment variable

  • TFS_WORKSPACE - The name of the workspace.
  • TFS_WORKFOLDER - The full path to the working folder.
  • TFS_PROJECTPATH - The project path that is mapped to the workspace.
  • TFS_SERVERURL - The URL to the Team Foundation Server.
  • TFS_USERNAME - The user name that is used to connect to the Team Foundation Server.


The plugin requires that one of the below command line tools is installed on the master and slave machines.

Microsoft TF CCL

The Visual Studio Team System 2008 Team Explorer is a free tool to access Team Foundation Servers. The TF.exe tool is installed into the Visual Studio folder that may be located at c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe

Teamprise TF CCL

The Teamprise Command-Line Client can be used on most platforms that support java.


opentf is an open source implementation of the TF executable, that can be used on platforms that support mono.

Current limitations

Because of issue 9 it is not possible to use the "Use update" feature. The workspace has to be created and removed in each build, which unfortunately makes checking out code a lot slower.

Because of issue 7 is it not possible to get a list of changes for a build.


How should I set up the plugin for my CodePlex project?

  • Find out the TFS server for your project, which is displayed in the source code page for your project at
  • The user name must be suffixed with _cp and the domain is snd. If your user name is redsolo, then enter "snd\redsolo_cp" as the user name in the plugin configuration.
  • Note that the user must be a member of the project to be able to create a workspace on the Team foundation server.

Thats all you need to start retrieving files from your project at

The plugin is having problems parsing the dates that TF outputs, what can I do?

The TF command line outputs date according to the locale and Microsofts own specification. Sometimes the outputed date can not be parsed by any of the default locale dependent parsers that the JDK includes (for some more details, see issue #4184 and issue #4021). This will throw an exception in the change set parsing and fail the build.

To fix this, do the following:

  • Change the locale by Windows Regional Settings to United States and English on the server and all hudson nodes. After that tf.exe should output dates in english, which can be parsed properly.
  • Start Hudson using the UnitedStates, English locale. Either set it using -Duser.language=en on the command line or check the documentation for the container that Hudson is running within.

Plugin version information

Road map


  • Add tagging support

Change log


1.12 (Jan 4 2011)

  • Fixed so changes that was committed after the workspace was updated is not included into the change log. (issue #6596)
  • Fixed so the date is parsed using the correct keyword. (issue #6454)
  • Updated plugin so it works with the TEE command line tool. (issue #6870)
  • Added support for change sets that has been checked in by a user not responsible for the change. (ie /Author checkins) issue #4943)

1.11 (Feb 1 2010)

1.10 (Dec 30 2009)

  • Changed user and domain name regex to be more lenient than only accepting lower case characters. (issue #4600)
  • Updated code for more recent Hudson

1.9 (Aug 31 2009)

  • Updated TFS SCM to conform with changes in base SCM class. This fixes the NPE when polling a server. (issue #4325)


  • Fixed so when a workspace is removed or wiped on a node, or when the project is deleted or renamed, the TFS workspace will be deleted. (issue #2208)
  • Fixed a problem when TF command line tool outputed dates containing p.m. which is not recognized by the default date parsers. (issue #4184)
  • The TFS workspace is no longer removed during a build, instead it is removed at the begning of the next build if the Use update flag is not set (issue #3778)
  • If workspace name, project path or local folder is changed in the configuration; the next build will remove the TFS workspace and create a new one with the new configuration. (issue #3784)


  • Updated regular expression to avoid StackOverFlowError while parsing long changesets history data (issue #3683)
  • Added TFS_PROJECTPATH, TFS_SERVERURL, TFS_USERNAME to the environment variable list (issue #3784)


  • Fixed a problem with diff links for the Team System Web Access repository browser (issue #3780)
  • Fixed a problem when comments contained forbidden XML chars (such as &, <, >, etc), which would throw an exception when trying to load the change log. (issue #2229)


  • Fixed a problem with interfacing with the tf tool on linux (issue #2241)
  • Fixed a problem with name casing in a resource folder (issue #2229)
  • Fixed a problem with workspace names containing a space (issue #2264)
  • Fixed a problem if the workspace already existed on another computer it was deleted at the end of the checkout (issue #2268)
  • Added the macro ${NODE_NAME} that can be used in a workspace name
  • Added very basic support for the opentf client (issue #2277)
  • Fixed so the workspace name and work folder path are available as build environmental variables (issue #2266)
  • Fixed so the build is not failed if the TF tool returns a exit code for partial success (exit code=1)
  • Fixed so invalid characters in the workspace name are replaced with _
  • Added support for paramterized builds (server url, project path and workspace name can contain build parameters) (issue #2302)


  • Improved support for Team System Web Access; added links to file content and diffs to previous version.


  • Added support for Team System Web Access repository browser. Now the Changes page has links to TSWA.
  • Fixed a bug where the work folder was not cleaned between builds if the job is not using the update feature.


  • Quick release for supporting older Hudsons than 1.234


  • Initial version supporting Microsoft and Teamprise command line clients.


plugin-scm plugin-scm Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Jun 14, 2010

    Joe Mash says:

    There appears to be an issue on the Changes page for a given changeset "Version"...

    There appears to be an issue on the Changes page for a given changeset "Version" link.


    Currently the URL is set to somthing like: http://<someserver>:8090/UI/Pages/Scc/cs.aspx?cs=70239

    However, TFS 2008 requires: http://<someserver>:8090/UI/Pages/Scc/ViewChangeset.aspx?changeset=70239

    Note: My Build Repositiry browser is set to "Team System Web Access" and Example URL to change set page: "http://<someserver>:8090/UI/Pages/Scc/"

    I have changed as many settings as I can find in hudson - it looks like the ".aspx" URL is listing the wrong page name for TFS2008

    It would be nice to just append the id's of a given changeset in the TFS plugin code and let the URL be completely configured in hudson.

    For Example:

    URL - http://<someserver>:8090/UI/Pages/Scc/ViewChangeset.aspx?changeset=

    Then append the changeset id for any links on the changes page in hudson.

    1. Sep 07, 2010

      Bogdan Iosif says:

      Raised an issue for this problem. See

      Raised an issue for this problem. See

      While your observation, diagnostic and description are all pretty good, please use the issue tracker in the future to signal this kind of problems because in this way there is a much better chance to see it solved and you will be able to better track the problem and get notified as soon as a solution is found.

  2. Jul 27, 2010

    NIkolay Bondarenko says:

    +1 to Joe Mash issue. Also have a trouble with locale encoding. We have non...

    +1 to Joe Mash issue.

    Also have a trouble with locale encoding. We have non latin (russian, win1251) comments in tfs checkins, so "changelist" in hudson show abracadabra instead of russian letters.

  3. Aug 03, 2010

    Ken Beal says:

    Hi, In version 1.8, several fixes were made to clean up workspaces when things ...


    In version 1.8, several fixes were made to clean up workspaces when things changed. We just ran into an issue after changing the username which accesses the TFS box (we were using an employee's credentials, and changed it to an account created for the build team). This caused builds to fail with the error (details hidden in angle brackets):

    The working folder C:\WINDOWS\system32\config\systemprofile\.hudson\jobs\<JOBNAME>\workspace is already in use by the workspace <JOBNAME>;<USERNAME> on computer <COMPUTERNAME>.

    In order to get the builds to work again, we had to first put the old user back; then wipe out the workspace; then configure the new user. Now it builds correctly.

    The key to getting this to work was seeing the description of the fixes that went into 1.8, so thanks for having that up here!

    Would it be possible to fix it so that, whenever the user defined for a job is changed, that job's workspace is wiped out similarly, so nobody else will get the "already in use" error above?


  4. Aug 06, 2010

    Ken Beal says:

    Hi, Our build environment requires supporting tags.  Any idea when this wi...


    Our build environment requires supporting tags.  Any idea when this will be completed?  (It's in the road map for "1.x", but does not have a date or a ticket number associated with it.)


  5. Jan 05, 2011

    Ken Beal says:

    Hi, I see this page reflects the new version 1.12 which fixes the "unparseable ...


    I see this page reflects the new version 1.12 which fixes the "unparseable date" issue, which we've eagerly been awaiting. However, the latest download still points to the 1.11 version.