I have a TFS 2015 Build and Release task and as part of this task I would like to take the output from the build and put it on to a server share under the version number of the software.
E.G.
\Server\App\Build\Versions{VersionNo}\
The "Copy and Publish Build Artefacts" tasks does something that is very close to this by setting the drop type to share. The structure isn't exactly what you're after though.
Instead you can also use a standard File Copy task or even a custom powershell script. The name of the build definition and the build version number are available as variables, so it's not hard to create the folder structure you're after.
Related
I am new to the world of scripting with TFS2015. I created a script that builds all of the projects within my solution (it is a rather large solution) and puts it out in a shared folder (where each project has its own subfolder).
I would like to create a separate script for each project that simply copies the bin folder from the shared and pastes it out on my Test environment. I rarely need to deploy everything, so the idea is one build...multiple deploys.
However, when I run my deploy script using the Copy Files step it is doing another build. Although it copies the files that I expect, it is after a full build that creates the folder structure for the build.
Am I able to make the Copy Files step NOT do a Build?
Here is the steps that my script is curently doing:
As you can see, there is only one step (Copy Files) but it still does the Get sources and copies everything into a new folder on the build box like so (where the number keeps incrementing up with each run of the script):
I just want to copy the files from the Source to the Target and not do a build or Get Sources.
It looks like you're still on TFS 2015 RTM or Update 1. Which is already pretty old technology if you compare it to the lifetime of the new build system which was introduced with this version.
TFS 2015 update 2 has introduced a similar system to the Build pipelines to orchestrate Releases. This doesn't require you to map any workspaces or git repositories and can act on the artefacts of your builds or simply on the contents of file shares.
It makes sense that a Build has to build something and in order to build something, it has to get the things to build. If you're actually not building something, then you're probably deploying or releasing or packaging something else. Hence the distinction between Build and Release pipelines.
TFS 2017+ has an option to disable the syncing of sources. Primarily to allow people to get the sources themselves in creative ways (e.g. a custom powershell script that invokes git.exe).
My primary advice would be to upgrade to TFS 2018 update 3 or at least TFS 2017 update 3.1, worst case TFS 2015 update 4.1. The fact that versions older than update 2015.4.1 have a known XSS scripting security bug may be reason enough to convince your organisation to perform this update.
Barring that option you're left with one solution:
Link your build definition either to a git repository with only a single commit (If I remember correctly the 2015 agent still crashes when syncing an empty Git repo) or link it to a TFVC repository and set the workspace settings to cloak everything. This essentially causes the build to sync an empty folder, which it can cache, before calling your powershell script.
I have two different TFS instances. Both use TFVC as a source control.
I want to set up a build definition on TFS1, so that it gets sources from TFS2. Is it possible to do it?
There is no option "Remote TFVC", only "Remove Git".
Thank you.
As far as I can tell, it isn't supported in either TFS On-Prem, or VSTS. Depending on your needs, circumstances and limitations, you might consider one of the following options (all are more or less trade-offs):
Migrate sources from TFS2 to TFS1 (the one to run builds)
This seems to be the correct thing to do, but it is a time-consuming and error-prone process
Fake the Get Sources action and do the real get/checkout in the first build step
You can configure the Get Sources step to address any Git repo in the same team project, and turn the Don't sync sources flag ON. Then, in the first real build step, run command-line Get (something like this)
You may use custom build step (cmd or bat file) and download files from remote server. Examples:
Copy files from tfs versioncontrol to directory with PowerShell
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9559f7a5-405a-456c-a66b-8123d52ed23a/how-to-copy-a-folder-from-tfs-source-control-to-shared-location-with-powershell-script?forum=tfsgeneral
You could just add the extension to get them from an external vsts/tfs.
Go to the marketplace and search for them (see image).
You will have to configure a endpoint to your external vsts/tfs, but it is quit easy to do.
You can install this extension: TFS artifacts for Release Management.
Then add a Download Artifacts-External TFVC task from Utility.
I am not a developer nor am I the Application Lifecycle Manager. I pull the latest builds from TFS Build Server along with the latest code and I import them in AppScan source for analysis (security tool). Against each security findings there is a class name within which the findings were found along with the directory where the class is located.
Builds are created automatically during a certain time of the day. As mentioned earlier the directory names change every time after a new build and a new number (highlighted below) is introduced. It is not sequential, does anyone know of TFS build server assigns these numbers.
C:\Builds**12**\Development
C:\Builds**14**\Development
C:\Builds**13**\Development
C:\Builds**15**\Development
TFS will create folders based on the following.
DriveLetter\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
so if you have 1 controller with 4 agents on a clean install you would get
Drive:\Builds\1\$(BuildDefinitionPath)
Drive:\Builds\2\$(BuildDefinitionPath)
Drive:\Builds\3\$(BuildDefinitionPath)
Drive:\Builds\4\$(BuildDefinitionPath)
Your Build definition is the name of the build definition and then each subsequent build is stored underneath, with each individual build getting its own folder.
these settings are available on the Build Agent properties screen.
These are transient files and you cant rely on them being there. They are only used as part of the build. You would be better doing a "Get" from TFS at the appropriate Changeset number for the build and using the binaries from the drop folder.
I have managed to chain two TFS builds together using Jason Stangroome's chaining build definition template. This gives me the capacity to execute one build definition after the next:
CertificateRepository-CI (Continuous Integration Build)
CertificateRepository-IntegrationTests
The latter will automatically be executed if the former is successful. I am stumped by the lack of Build Definition Templates that are able to download and extract the contents of the preceding build's drop folder and perform actions upon these artifacts, in this case running SpecFlow/NUnit integration tests.
In this case I am using:
Visual Studio Online
Git for the codebase being tested
TFVC for the ALM components (NUnit Adapter, Build Definition Templates)
Any help greatly appreciated.
If you are using TFS for source control: I don't have a template for this but you can follow below steps to achieve this.
In CI build set the Staging Location option to Copy buildoutput to following Source Control folder
Download the drop folder by mapping it in source settings option
in build definition
Under drop location folder in TFS, every CI build will create a new folder, you need to pass this folder name to the second build definition. Please check another post from Jason for passing parameters to second build
Execute the tests by invoking the commandline tools using Invoke
Process activity.
I have been using a msbuild file that builds and packages my solution to 'Client' and 'Server'. So far I have been using the below cmd to build from VS cmd prompt:
msbuild.exe MyBuildFile.proj /t:Build
(I have a target called 'Build' which will kick start build and do the rest).
Now, my team wants to queue builds in TFS build server. I read about TFSBuild.proj file. Should I once again write all the scripts in to TFSBuild.Proj or is there a way by which I can call my 'MyBuildFile.proj /t:Build' from TFSBuild.Proj.
Any help is appreciated.
Thanks, Mani
You can just include your existing MyBuildFile.proj in a TFS 2010 build:
Create a new build definition
In the Process page, choose the UpgradeTemplate.xaml workflow
Select the directory of your checked-in MSBuild.proj file of choice (checked-in under the name TFSBuild.proj)
There might be some subtle differences between your development system and the build server that you need to take care of, but above steps should take you 85%. Enable Diagnostic level build information verbosity (also to be set on the Process page) to troubleshoot loose ends.