We want to create a TFS Build Template only to trigger my power shell script for deployment.
We do not want to build any project or solution as part of this process definition.
We tried editing the process template workflow and removed build related actions but still when I open the edit process template I am prompted to provide project to build in Build section.
We do not want to include our deployment script in any other build definitions as we want to decouple deployment and configure separately.
I have seen some similar questions in StakOverflow but those suggestion are create some fake projects or fake solutions to attach it. But I am looking for completely removing the build section from the build definition.
Remove the workflow arguments that you don't require when editing the workflow (specifically the BuildSettings argument).
Related
Is this possible to build only a single project and its dependencies specified in a pipeline script?
If I have a Visual Studio Solution with multiple projects, and websites, and I want to build and publish only a specific website and it's dependencies, how could it be done when using DevOps Pipelines, so it does not build the whole solution, but only the required projects for that specific website.
If you want to only build a single project in your solution, you could use the MSBuild task in Azure Devops Pipelines and then point it to the project you want to build.
Another way would be to in your VS solution to edit the Configuration Properties. In the Configuration Manager you can create a Configuration called Single_Project or something like that and then in the properties select which projects to build when using that configuration. Then when you use the VS Build task and specify the configuration you created for your build.
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.
How do I or can I, create a hierarchy of build definitions in TFS 2012?
I currently have a master build script (.cmd) that calls multiple child scripts (.cmd).
I want to migrate this to the TFS build system and maintain the hierarchy.
I can't seem to figure out if this is possible using the TFS 2012 build system.
Here's what I'm talking about:
MasterBuildScript.cmd
call componentscript1
call componentscript2
call componentscript3
call ...
call packaging routine for all components
componentscript1.cmd
build solution componenta1
build solution componenta2
build solution componenta3
...
componentscript2.cmd
build solution componentb1
build solution componentb2
build solution componentb3
...
more components...
Is there a way to do this with the standard TFS 2012 Build Definitions?
- Bruce
There is a way to do this without doing any custom coding. You will have to make a minor addition to a build process template, however. That doesn't use code, it uses Windows Workflow Foundation.
Essentially, you would need to setup TFS Team Build definitions for each .cmd build script that you currently have. One for the master build, one for each component build. The real work involved here is converting your .cmd script into a TFS build definition.
Then, to auto queue the "child" builds, you can edit the process template for your master build definition and add an "InvokeProcess" activity - this lets you shell out to the command line as part of the build process. You can use the command line utility TFSBuild.exe to kick off the "child" builds. http://msdn.microsoft.com/en-us/library/aa337622(v=vs.90).aspx
I've used something similar in the past where I have a build for my core set of assemblies. That build then kicks off all of the builds which have dependencies on those assemblies.
Have a CI build set up in a very simple solution (MVC webapp, Service, MSTest project)
The build shows orange with the following:
Handle MSTest Exception There is no working folder mapping for
/Heartbeat/Source/BvtAutomation/Local.testsettings
Now, here's the kicker, that is not the source branch being built, it is another project altogether! I cannot find any reference to it in the build definition or anywhere in my solution (WinGrep .. the whole nine yards!)
Anyone seen anything similar to this or have a suggestion as to what I might try?
Thanks!
In TFS2010 when building with DefaultTemplate.xaml, the test files to run are not specified relatively to the mapped workspace, but instead by their complete path from Source Control.
So to fix the issue:
Edit your build definition
Go to the Process tab
In the 2. Basic section, select Automated Tests and click the ... button to edit the test settings.
In the Automated Tests dialog, browse for the .testsettings file in the branch you're building.
This may help: select build definition in the Team Explorer, right-click -> Edit build definition. On the 'Workspace' tab you can configure sources to be got to the build machine. HTH
I understand I can write my own custom activity (in C#) to execute custom logic during the build process. My understanding is that Powershell can also be used, but I am not sure where it fits in. I do understand Powershell is used for executing command line commands but how and where would I use it to customize the build process?
Thanks
The decision whether to use Powershell or a Custom activity is for me based on who is responsible. If you have an activity that is created by the build master (for TFS) and therefor reusable for all the teams in the organization, I create a custom activity.
If the project team is responsible (for example a deployment script), the I use the powershell. I create an argument where the team can enter the path of the powershell script that needs to execute to deploy. The project team can optionally choose to enter a value in that argument. The project team can also maintain their powershell deployment script themselves without the help of the build master.
So in short:
A reusable activity: Custom activity
Activity for the team only: Powershell
For me, powershell is the way to go. Here are my reasons why:
Script Independence:
You get script independence using this approach. Example: I have a number of scripts that run after the build (i.e. the compile) process has completed:
Instantiate Database
Deploy Database Code
Deploy Web Applications
Verify Deployment
Run Acceptance Tests
All of the above can be launched, debugged and tested independently without the need to queue a new build.
Powershell is easy to work with:
Custom assemblies tend to add a lot of complexity and flakiness to the solution. Example: Upgrading from TFS 2010 to TFS 2012 was very painful, because all of the Build Templates broke. We had to recompile all of our custom assemblies, and only one dev on the team knew how TFS Build was set up to run our custom activities. I have recently removed all custom assemblies from our build templates, and am using Powershell exclusively.
I have customised my process templates to call a user-defined powershell script after the TFS Build has completed. I do this by using a paths argument in the build definition. This argument is simply an array of strings pointing to the scripts. I agree with Ewald, above, that TFS does not pass the build arguments to scripts. To solve this, in my workflow template I parse each script in the string array, and replace well-known tokens with the build arguments - e.g. #(BuildNumber), #(SourcesDirectory) etc. I find this to be a very easy and solid solution.