I want to make a build definitios in TFS 2015 that copies all files in a repository to a given UNC.
This is not a VS project, but a set of web files that all are compiled.
Any ideas how this can be solved?
Copy Files task exists in TFS 2015.3 and newer versions. You could upgrade your TFS 2015 to the latest edition TFS 2015.4 and use this task.
Otherwise, you could use Copy and Publish Build Artifacts task, which is available since TFS 2015 RTM.
I ended up writing a PowerShell for the job.
#
# Deploy.ps1
#
param (
[Parameter(Mandatory=$true)][string]$targetPath
)
Function Deploy-Package() {
Copy-Item "$Env:BUILD_SOURCESDIRECTORY\*" $targetPath -Recurse
}
Deploy-Package
Write-Host -ForegroundColor Green "Deployment successful"
Related
On our build server, we have a space disk problem. After investigation, we found a lot of te.processhost.managed_xxx_xxx_xxx.itrace files in C:\Windows\Temp. It's take nearly 50Go.
There were created on a process building in TFS 2015 vNext, on the task Visual Studio Test but there are never delete automatically.
There were not created if we disable Codecoverage option (but we need this option of course).
How can we disable automaticaly creation of these files ? Or automaticaly delete these files in the process (without script) ? Any option ? Other idea ?
From TFS 2015 Update 3 (upgrade your TFS if your version is lower than this Update 3), there is a task named Delete files, you could add this task after Visual Studio Test task to delete the .itrace files.
I faced the same issue with build agents of version 2.122.1, "Visual Studio Test 1.*" and TFS 2017 Update 3.
I worked around it with a scheduled run of the following PowerShell script:
get-childitem -Path $env:SystemRoot\Temp -Filter *.itrace | where-object {$_.lastwritetime -lt (get-date).AddHours(-1)} | Foreach-Object { del $_.FullName }
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
We currently use TFS 2013.
I'd like to do a POC where I can create some build definitions in TFS 2015 where it would get the source from our existing TFS 2013 server. Once the boss sees how much easier it is to manage our builds from TFS 2015, I'm sure he'll give us the go-ahead with upgrading the existing TFS 2013 to TFS 2015.
Is this even possible?
You could write a PowerShell script or some batch files to leverage tf.exe in order to map a workspace / clone a repo (depending on whether you're using TFVC or Git) as part of a build. Or just put the tip of your source code into the "demo" environment and build from there. The latter option is going to be much faster.
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.
I am trying to modify my project so that on build it queries for the current TFS changeset for the local directory and uses that to form the build number (using http://florent.clairambault.fr/insert-svn-version-and-build-number-in-your-c-assemblyinfo-file as a reference).
Since we currently are not using team build or any continuous integration for this particular project at this time I plan to use:
tf history . /r /noprompt /stopafter:1 /version:W
However, when I test this command out using the visual studio command prompt in my project's directly (where I work from TFS) it claims:
There is no working folder mapping for xxxxxxxx
The folder is shown as mapped in my workspaces in Visual Studio's Source Control Explorer (shows as the local path), and when I edit my workspace.
Why is the command line utility claiming there is no working folder when it is?
You will see this error message if you are using Visual Studio 2012 (and the corresponding Team Explorer 2012 client) and you are using tf.exe from Team Explorer 2010.
TFS 2010 clients store their local workspace cache in a different location on-disk than TFS 2012 clients. Thus, if you are to create a workspace with a TFS 2012 client, the TFS 2010 client cannot see that workspace data until it has connected to the server and populated its own local client cache.
It sounds like you're okay with using the TFS 2012 version of tf.exe, so I would make sure that your PATH contains an entry to that one first, and this should resolve your problem.
If you really wanted interoperability between the two versions, you would need to make sure to connect to your TFS server from both clients in order to make sure the workspace cache was complete for both. However make sure that you are using only server workspaces in this case, as TFS 2010 cannot connect to a TFS 2012 local workspace.