Provide build configuration dependencies in TFS Build
Provide the ability to create build configuration dependencies such that the success of one build configuration can trigger another build configuration such as a successful build triggering the building of an installation package or a build configuration which deploys to a development or staging server. Other tools such as Cruise Control.Net and Jetbrains TeamCity already offer build configuration dependencies/build configuration triggering through various means, therefore, TFS Build should also provide this type of support.
This is a great idea! Although we plan to make this available to you in the near future, we are still in the planning process. We will check back as soon as possible with any updates to this request. Program Manager TFS
Greg Pakes commented
I still can't see this on the features timeline https://www.visualstudio.com/en-us/news/release-archive-vso.aspx and that goes through to the end of 2015.
TeamCity is looking like a good choice now.
Greg Pakes commented
Why don't you just create a new build to run in the morning that only runs a Clean?
Peter Anderson commented
When you say 'in the near future' how near are we talking?
We want to run a clean each morning for a given build definition (the definitions normal behavior is Gated without clean). If there is a nice way of doing this now that would be great :)
Ankur Garg commented
I am looking for same functionality. Please make it available soon and share the plan when it would be released
I need to configure build of multiple components, each component has its solution file. Now, there are dependencies between them at dll level (dll of one component could be referred in other componnent). For eg, if component A builds, it produces few dlls. Now, these would be referred in component B build. So, need to define dependency between these components A and B. If component A builds, then once comp A build completes, it should trigger build of comp B And latest dlls of comp A to be used in Component B build definition.
What I am looking for how to add dependency (parent/child) between different build definitions and artifacts sharing in TFS something similar to CI tools like TeamCity, Bamboo etc. Please suggest options in Team Foundation Server
An upper environment lab deploy picking up the build output of a lower region lab deploy/build based on build status ( contingent on successful coded CI test)
dependency build will help a lot,
two points from our side to this Idea:
- trigger scheduled (e.g. every 5 minutes)
- CI based on only parts of the source control nodes (e.g. if you hook up some general test environment solutions to a Build, there is no need to run a CI build on a check in for a this part)
Josh Ho commented
Has there been any feedback from MS about this request? It's been over a year -June 2013 since it was marked as "Under Review". The initial idea was shared all the way back in August of 2011...is MS even reviewing UserVoice any more?
TFS is a Build Server "Lite"
1. Build projects which depend on a given project
2. Build project A using VS 2012 and project B using VS 2010 in the same TFS build definition or as a dependant project. This is to handle projects supported in VS 2010 but not in 2012
Please review the custom build actions written in C# code for TFS and include many more in TFS. This is an addtional X hours of re-work for us in maintaining them when upgrading from TFS 2010 to 2012. These were nothing special, copy files, if file exists, rename file, create directory, copy directory, insert build number in assemblyinfo.cs.
Brian Christman commented
We already have this functionality thanks to custom coding I've done for our teams.
Shikhar Jain commented
At my client side I have implemented something very similar to this feature request.
Scenario: I have about 50 build definitions spanned around multiple team projects. Builds for next applications are dependent on previous applications build. Build for next project in list should be queued only if previous build is successful. If any build in list fails then entire build should fail. However after you fix the failed build and queue the new build, you should be able to resume from last failed location.
1. Custom build definition which takes build definition name and team project name as input.
2. Have configuration to queue new build or resume from failed build in the list.
3. You can add any number of build definition to create the list and index them appropriately to specify the dependency.
Where? When I try to find the code you linked to I get "The thread does not exist."
Paul Knopf commented
This is already available with some modifications to the build process template and the usage of the TFS Build extensions.
Anyone know if Microsoft is planning to implement this feature?
I'd also like to be able to prevent one build from running while another is running.
Michael Paterson commented
Build A succeeds -> Build B is triggered.
Personally I'd prefer to set this up in Build B to "watch" Build A then have Build A specify that Build B should be triggered.
Yes, i agree. TFS provides some marvellous features, but not the feature to configure dependencies between severals builds.
If build A depends of the build B, when the build B is triggered, the build A is queued and after the Build B must be queued.
"* As a property of a build definition, let me specify a set of build definition on which it depends - those should be built if prior to building the one that depends on them if the latest changeset affecting them is more recent than their most successful build."
Exactly what we are looking for.
This would be a fantastic feature. Right now I have to have one huge build to compensate for this. It makes building a subset of the product more complex.
*It would be great to have a property on a build that would be a list of builds. When the build succeeds, it will go to that list and start those builds.* (This would allow chaining.)
As a separate (far less important) item, it would be nice to say: running this build will cause these other builds to run first. (As I said this is far less important than "chaining" outlined above.)
Christian Mogensen commented
We would like something similar to CruiseControl.net - where a successful build A can be a trigger for build B.
That fits this definition, modulo the stuff about latest changeset.
* As a property of a build definition, let me specify a set of build definition on which it depends - those should be built if prior to building the one that depends on them if the latest changeset affecting them is more recent than their most successful build.
The variation "* As a property of a build definition, specify one or more build definitions to be queued if it is built successfully. " is the inverse of this - but this places the dependencies on the source, rather then the dependents, which may be simpler to understand and manage.