I need to check-in some files generated during a TFS 2017 vNext build.
In my old XAML build I could easily do that using the tf checkin command since the files reside in the build workspace.
In the new vNext build, The workspace owner is Project Build Service or Project Collection Build Service, even when I configure the agent to run under a different account.
Any way to perform the check-in on the build workspace? Or somehow configure who owns that workspace?
There are Add and Check in changes tasks in TFVC Build Tasks extension.
Regarding no pending changes, you need to add the files to the list of pending changes for the workspace by calling TF add command.
It's not a recommend way to check-in/ modify source code during a build pipeline. If you really want to do this, you could edit the build worspace files and use tf commands in custom/powershell task eq:
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 1x.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Another way is installing TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for more details: PowerShell and TFS: The Basics and Beyond
Related
I am trying to run a Jenkins job that uses TFVC plugin. We earlier had a problem with length of the TFS workspace names (exception for length > 75 chars). In order to address this we made a change in the TFVC configuration.
Default workspace name in TFVC: Hudson-${JOB_NAME}-${NODE_NAME}
After change: Hudson-${JOB_NAME}
Post this change the job had one successful run. We are unable to run this repeatedly as the TFS workspace created during the successful run was not deleted. and is throwing the following exception:
FATAL: hudson.remoting.ProxyException: com.microsoft.tfs.core.exceptions.TECoreException: The workspace scanAPI;tfsjenkins already exists on computer ip-XX-XX-XX-XX.
I have tried deleting the Jenkins workspace in pre/post build steps. This has no impact on the TFS workspace.
Additional information: The jobs are being run on a linux node and hence I am unable to run windows commands
You can use Post Build script that use tf.exe to delete the TFVC workpsace, with the delete command.
Create a global environment variable to be able to access the TF.exe easier. for example:
Note: the path to tf.exe it depend to which Visual Studio is installed in the Jenkins machine.
Add a Windows batch command from the scripts menu with the following command:
%TFS% workspace /delete /noprompt /collection:”https://tfs.codeplex.com:443/tfs/TFS27″ “Hudson-%JOB_NAME%;snd\7astlivec_cp”
Replace the URL with your TFS Server URL and change snd\7astlivec_cp with your TFS user. The command is going to delete the newly created TFS workspace.
Another option is to add tf.exe. location to the machine PATH variable and use it directly: tf workspace /delete .......
Update
For Linux, you should be able to use this through team explorer everywhere. It also include a tf command line.
Take a look at Setting up a workspace using Team Explorer Everywhere on Linux
Should be similar on Linux.
Instead of creating the default workspace by specifying workspace name in UI setting, you could also use a Windows batch command to handle this process.
If you want to delete workspace, just add a new post build step, a cleanup command could be added to delete the previously created TFS workspace.
%TFS% workspace /delete /noprompt /collection:"{your-tfs-team-project-collection-url}" "Hudson-%JOB_NAME%;{your-domain-user-name}"
More details your could kindly refer this step-by-step tutorial Jenkins Get Source Code By Specific TFS Changeset
Is there any similar plugin like this
https://wiki.jenkins.io/display/JENKINS/Config+File+Provider+Plugin
in TFS Build & Release
I want to provide configuration.json file which is not included in git source.
Unfortunately, there is no such extension in TFS/VSTS Build & Release.
According to your tag tfs2013, seems you are working with XAML build.
Just like you need a workspace on your dev machine to develop your app, you must specify the workspace that the build agent uses to build and test your app. Then we get/pull source files from TFS server side. It's not able to achieve below similar features in TFS UI:
Adds the ability to provide configuration files (i.e., settings.xml
for maven, XML, groovy, custom files, etc.) loaded through the Jenkins
UI which will be copied to the job's workspace.
As a workaround, you could try to put configuration.json files in a ftp server instead of git source and then use a PowerShell solution to down the files in build agent workspace. If create a PowerShell to over FTP you can have it called by the build template(customize workflow).
I have created a Jenkins Job which gets code from TFS and builds the EAR at jenkins default workspace (/opt/jenkins/lib/jobs/PROJECTNAME/workspace/dist).
After the EAR is built, I need to checkin this EAR to TFS, but I didn't see any option to checkin artifacts to TFS.
If you are using TFS Plugin in Jenkins to get the code from TFS. It will create a workspace when get the code. Settings as following:
And then, you can add an "Execute Windows batch command" build step to check in files to TFS after EAR build via TF Command.
Now you'll get the files been checked in:
In the command, I check in the folder generated by the build, you can also just add the items generated by the build.
might be helpful.
Visit how to add an existing solution to tfs
Another add solution to TFS server
I have configured TeamCity to work with our TFS repo. I have configured the VCS Root and used the "Test Connection" to ensure that the settings are all correct. When I run a build it gets to the "Updating sources" and just hangs there. Here's the build log.
[13:33:45]Collecting changes in 1 VCS root
[13:33:47]Clearing temporary directory: D:\TeamCity\buildAgent\temp\buildTmp
[13:33:47]Publishing internal artifacts
[13:33:48]Using vcs information from server. Reason: no revision information for build configuration "Build Development trunk" and checkout directory D:\TeamCity\buildAgent\work\db23c120e1319dcb on agent
[13:33:48]Clean build enabled: removing old files from D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Checkout directory: D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Updating sources: server side checkout (1m:21s)
[13:33:48][Updating sources] Will perform clean checkout
[13:33:48][Updating sources] Clean checkout reasons
[13:33:50][Updating sources] Building and caching clean patch for VCS root: Development trunk
The checkout folder is empty. Any ideas?
EDIT
I've written a Windows batch file that gets the code out from TFS rather than using TeamCity to do this. My batch file runs perfectly when run from the Windows command prompt but fails when run from TeamCity. I am using the fully qualified path to TF.EXE because TeamCity doesn't seem able to find TF.EXE (even though the path has been added to the PATH environment variable).
My batch file correctly configures the TFS workspace before trying to GET the source code. But it still fails.
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /collection:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /s:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workfold //fails!!
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" get $/MSM\Development\Trunk /force /recursive //fails!!
The error I am getting is "Unable to determine the workspace. You may be able to correct this by running 'tf workspaces /collection:TeamProjectCollectionUrl'"
But as can be seen I am already specifying the workspace in the batch file.
Any ideas why these commands work from the Windows command line but fail from TeamCity? How do I get them to run from TeamCity?
The solution in my case was to upgrade my Team Foundation Client from 2012 to 2013. There are known timeout issues with the 2012 version and upgrading to 2013 has resolved these.
I had the same issue (TeamCity builds that fetched code from TFS would get stuck indefinitely at the Updating sources stage, blocking the agent).
The solution for me was to make sure that the TeamCity Build Agent ran under the same service account as the TeamCity Server. The server would be able to access the TFS project and instruct the agent to do a build, but the agent itself got stuck when it was not authorized.
When that account mismatch was fixed, it all started working as it should.
As a side note, when the parameter “teamcity.tfs.mode=java” is set, the TeamCity agent does not get stuck, but instead fails with an instructive error message (detailing the current service account name), if it runs under an unauthorized account.
I am trying to set up an automatic build.vnext process for TFS 2015. This build process contains one Visual Studio Build build step, in which a .nupkg package file is created in the build agent's bin/Debug and bin/Release directories.
I have a private NuGet-Server installed on the same server as the build agents are running on. I want to copy the generated .nupkg files from the bin-directories to my NuGet-Server's package-source-folder (say C:\Packages).
How can I do this with TFS 2015 Build.Vnext/Preview?
Edit:
I can easily copy all build output from the agents to the package folder by configuring the Visual Studio Build options "Copy to Staging Folder" Search Pattern to **/bin/*. This copies the folders myProject\bin\Debug and myProject\bin\Release folders and their contents to the package folder.
If I specify e.g. **/bin/**/*.nupkg or similar, nothing is copied, even though a respective *.nupkg file exists.
I found a solution to this problem:
Under Options set Copy to Staging Folder of the Visual Studio
Build-Configuration to true.
Use the search pattern **\bin*
Add a Command Line utility definition.
Let it execute C:\YourPathTo\nuget.exe with the arguments push C:\YourStagingPath**\bin***.nupkg -s [YourServer] [YourAPIKey]
Done.