This plugin integrates Microsoft Team Foundation Server source control (also known as TFVC) to Jenkins.
With this plugin you can use a workspace that will create a work folder in the Jenkins workspace. At the moment, this plugin supports:
The plugin will automatically create a workspace on the Team Foundation Server and map a work folder (in the Jenkins workspace) to it.
The following sub-sections list the various versions of software that were tested and are thus supported. The plugin might work with other versions, they just haven't been tested.
The plugin has been tested against Visual Studio Online, as well as the following versions of TFS:
Note that mainstream support for TFS 2010 ended 2015/07/14.
The plugin has been tested against the following operating systems and versions, with the latest updates as of 2015/08/27.
The plugin is built against Jenkins version 1.448 and that's the version integration tests are run against.
Ever since release 4.0.0, a TFS command-line client or tool is no longer necessary as all the interaction with the TFS server is done using the TFS SDK for Java. The native libraries needed by the SDK are automatically copied to a sub-directory under the agent user's home folder.
Versions 3.2.0 and earlier of the plugin required a TFS command line tool to be installed on the build agents that will be retrieving source code from TFS.
For [on-premises] Team Foundation Server, the user name can be specified in two ways:
For Visual Studio Online, there are also two options:
The plugin now supports checking out from a specific label. Here's how to configure a job to do that:
Now, the next time you want to queue a build, you will need to provide a value for the VERSION_SPEC parameter. The build will then perform a checkout of the source as of the specified VERSION_SPEC.
The plugin will set the following environment variables for the build, after a checkout:
That's all you need to start retrieving files from your project at codeplex.com.
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:
After version 4.0.0, the following pull requests will be revisited and updated for inclusion into a tentatively-titled 4.1.0 release:
Skip to end of metadata Go to start of metadata