How can we improve Azure DevOps?

Allow TFS build to depend on multiple repositories

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Many other build systems allow dependencies on multiple source repositories ( even different ones - i.e. Git and SVN).

I currently have setup a TFS project that has multple Git repos and TFS source repositories. I have builds that depend on a mixture - for instance a main build has a dependency on a Git repo that contains 3rd party dependencies. While there is a work around with the general command line support, it would be much more clear to define the source dependencies up front. I should be able to specify the branches on those via variables also. I know that TeamCity supports multiple source control repos. Take a look at that implementation.

423 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Jason shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Taylor Mansfield commented  ·   ·  Flag as inappropriate

    Isn't this something of an anti-pattern? If a build depends on several repos, isn't it impossible to reproduce any builds outside of TFS without a priori knowledge? For example, if I have a test library repo that gets built with a app repo, how would my developers ever be able to successfully run tests locally without knowing beforehand that you need both repos? Not to mention that you decouple the version of the tests from the version of the app. That makes it entirely inauditable. A solution to this is to use the test repo as a submodule to the app repo, but submodules come with their own set of problems.

  • Brian Thomason commented  ·   ·  Flag as inappropriate

    This is something my company needs as well, we have our Website in it's own repo, and the models/services is uses in others that are a mixture of TFVC AND VSTS Git repos.

  • Anonymous commented  ·   ·  Flag as inappropriate

    The feature should also be added for VSTS. When multiple repos can be specified for the same build, it will be quite convenient that one CI Build definition for multiple repos instead clone multiple CI build definitions for each repo separately.

  • Forrest Trepte commented  ·   ·  Flag as inappropriate

    My team has some custom build processes that we run a combination of multiple internal team repositories and external open-source repositories. Currently we have to have a single master repository with build scripts to manually clone the other repositories every time. If VSTS could support multiple repositories in the Get Sources part of the build definition it would save us a lot of complexity!

  • Kjetil Smith commented  ·   ·  Flag as inappropriate

    3 votes; why not publish the code to do "clone git's" in this repro:

    Since it's possible to add different repro'es in the old TFVC (same collection), but why not git. We have also looked at the git submodules:

    and the SSH public keys :


    The ideal solution should be to add different git repositories just as the simple one you clone;-)

  • alvipeo commented  ·   ·  Flag as inappropriate

    This would be great for Angular 4+ and .NET Core MVC projects. So when Angular 4 project is built, .NET Core MVC is also gets built afterwards.

    If there's another way of doing this, please let me know.

  • Stan commented  ·   ·  Flag as inappropriate

    Building multiple GIT repositories in a single Team Project needs to happen for VSTS because we can't use it until then. We'll have to continue using TeamCity instead.

  • Dan commented  ·   ·  Flag as inappropriate

    Now that TFS/VSTS allows for multiple repositories in a single Team Project, this is a much needed feature. I work as consultant in the DevOps space to recommend tools and help companies manage their SDLC's and mature their process. Recently on this topic I've gotten a lot of strange looks when I tell clients how they have to manage multiple repositories in a single build with TFS/VSTS. This should be easy for the end-users and built directly in the tool without the need for script hacking and/or git manipulations.

2 Next →

Feedback and Knowledge Base