I suggest you ...

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.

1,700 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    vs2010junkievs2010junkie shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    17 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Josh HoJosh Ho commented  ·   ·  Flag as inappropriate

        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?

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        Our needs:
        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.

      • Shikhar JainShikhar Jain commented  ·   ·  Flag as inappropriate

        Hi,
        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.

        Description:
        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.

      • KenKen commented  ·   ·  Flag as inappropriate

        Where? When I try to find the code you linked to I get "The thread does not exist."

      • EricEric commented  ·   ·  Flag as inappropriate

        I'd also like to be able to prevent one build from running while another is running.

      • Michael PatersonMichael Paterson commented  ·   ·  Flag as inappropriate

        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.

      • JulienJulien commented  ·   ·  Flag as inappropriate

        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.

      • TobiasTobias commented  ·   ·  Flag as inappropriate

        "* 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.

      • StephenStephen commented  ·   ·  Flag as inappropriate

        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 MogensenChristian Mogensen commented  ·   ·  Flag as inappropriate

        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.

      • Jim LambJim Lamb commented  ·   ·  Flag as inappropriate

        Let me ask you to clarify this one a bit as I see multiple possible interpretations. Can you tell me which of these apply?

        * Specify multiple platforms/configurations but build each only if the build of the previous one succeeded.
        * As a property of a build definition, specify one or more build definitions to be queued if it is built successfully.
        * 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.

      • K.RadewaldK.Radewald commented  ·   ·  Flag as inappropriate

        +1 for this suggestion. Having build configuration dependencies is highly appreciated for Continuous Integration. We utilized that in JetBrains' TeamCity and missed it sadly when we changed over to TFS.

      • Jim LambJim Lamb commented  ·   ·  Flag as inappropriate

        We've actually had this on our backlog for quite a while. it's really great to get the feedback we need to get it prioritized appropriately.

      Feedback and Knowledge Base