Triggering a build from another build(conditional) in TFS 2015 - tfs

I have created two build definition for two different builds in TFS 2015.
Ex - Build1 and Build2
Both the are getting executed without an error.
What I want to perform is, I want to provide an argument in build one
ex=Build2=True or False.
If the argument Build2=True after build definition Build1 successfully executed the build definition Build2 should get triggered.
And if Build2=False the build process should finish after execution of Build1.
I am able to do this in Jenkins by adding the Build2 to pipeline in postbuild tasks, since I am new in TFS 2015 so can anybody help me to accomplish this in TFS 2015

As #Yan Sklyarenko mentioned, this feature is not supported right now, please vote the User Voice at website below:
https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/2165043-provide-build-configuration-dependencies-in-tfs-bu

I created a Build Task that should allow to support your described scenario. It uses the TFS REST API to queue new builds and supports conditions, for example a check if the last build of a specified build definition was successful or not.
You can download it from the Marketplace

Another option is to create Task Group for each build.
you can read about Task Groups here
and create one build that use some task group in his steps.

Related

TFS17 on prem and fortify builds

I need to incorporate a task in my build to perform a Fortify Scan. My issue is I have one agent and scans take 1 to 2 hours, which ties up the one agent. I then tried to create a build that would start a scan of are TFS/SCM only to kill it after it ran for over 8 hours. Is there a way to create a task that only runs the changes for that day?
Since you are using Team Foundation Server 2017. As part of your build and release process you could execute Micro Focus Fortify security scans and upload the results to the Fortify SSC server.
It's also able to make the build/release fail whenever the scanner detects new critical or high findings in the code. We could use the Micro Focus Fortify plugin for TFS to configure the scan step and upload to SSC: (Fortify TFS plugin). Just add a PowerShell task afterward to attempt to query for findings and fail the build if needed.
Is there a way to create a task that only runs the changes for that day? There is also a concept called Scheduled Trigger which select the days and times when you want to run the build. Just make sure to check "Only schedule builds if the source and pipeline has changed" All support triggers are list here --Build pipeline triggers, please kindly take a look at it.

TFS 2015 and later - Tagging agents

Does anyone know if the feature to tag agents has dissapeared?
I could not find anything related to over the internet.
My idea is to have certain builds use a specific agent. On TFS 2013 I would use tagging, but i no longer see that option.
On the other hand, I see that it is possible to connect a build definition to a certain agent queue.
There is no more agent tags for TFS 2015 or later version. If you want to use a particular build definition and a specific build Agent which used to run the build.
You could add a user Capability to that specific build agent then in the build definition you put that capability as a demand (General tab).
Another way is directly using Agent.Name or Agent.ComputerName demands in build def or when queuing a build. Take a look at this blog: How to send TFS build to a specific agent or server, which also support on TFS2015.
Oren: Is this feature works in TFS15 SP3?
Reply Eric Parvin: Yes, this should work on TFS 2015 to the newest version.
Use demands and capabilities for this. Add a custom capability to the build agent, and then add a matching demand to the build definition.
Demands and capabilities would work, and you could also create a specific queue, with a single available agent in it, and set the queue to your desired build, so you would achieve the same behavior as desired one.

How to change multiple build definitions into schedule builds

we have around 300 TFS CI build definitions and now i want to change it into schedule build. Is it possible to change CI multiple Builds into scheduled.
Its really heck process to change one by one. I want some PowerShell or batch script to run the builds or any tool to change multiple TFS build definitions to schedule builds.
Thanks in advance.
You can use the TFS API to programmatically create and edit build definitions. Here is an example:
http://blog.ehn.nu/2010/04/creating-a-build-definition-using-the-tfs-2010-api/
Have a look at:
https://visualstudiogallery.msdn.microsoft.com/73bf2d8e-aec6-406c-8e7f-1c678e46557f
You should be able to change the trigger for multiple builds at once. I also created a set of powershell extensions to create/edit builds in bulk, but there is no CmdLet for the trigger yet, but have a look if you are interested in extending it (send me a pull request if you do ;)):
https://github.com/sanderaernouts/tfs-build-tools

TFS, Jenkins and how to update work items with build numbers

We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.

Discard build in case of failure

I'm creating a custom build process template that allows the person who is queueing the build to define the build and revision numbers (as they are used on the assembly version info).
However, if the build fails, they can't queue a new build for the same version (but they should be able).
Is there a way to automatically discard the build if any step in the workflow or MSBuild Script fails?
TFS maintains assigned build numbers in the database itself, for its own administrative purposes. This maintains its internal consistency with all the assets that are produced and (intermediate) work products.
The only way to free up a previously used build number is to actively DESTROY it from the database. Please see http://geekswithblogs.net/jehan/archive/2011/04/23/tf42064-the-build-number-already-exists-for-build-definition-error.aspx for a further explaination.
One of the features added in TFS 2012 is the ability to retry a build.
This allows you to right click a failed build and select retry instead of queuing a new build. This should allow you to run a build with the same configuration settings without getting errors on your build numbers.

Resources