Label build sources for all dependencies

There is no simple action to do that. You would need to manually attach all VCS Roots to the build configuration that does the labeling. You can select "Do not checkout files automatically" in checkout mode to prevent the agent from downloading all the sources, or create a new composite build configuration with the dependencies to add this feature, since composite builds work on the server only without downloading the changes.

We have a feature request to implement it directly on dependencies, feel free to vote for it: https://youtrack.jetbrains.com/issue/TW-44941/Make-source-labelling-work-for-dependencies-VCS-roots

Would be able to expand a bit more on the benefits/drawbacks of using a regular build configuration vs. composite build config for this task?

To give an update, I've been able to add a regular build configuration and I've also figured out how to attach all the dependencies roots. But I hadn't realized that I could optimize the build to not have to check out files.

Two things were not obvious to me:
1. that VCS roots can be setup hierarchically; and
2. that in order to be able to attach the roots of dependencies, the roots have to be defined at a project level that matches the level of the configuration that does the labeling (or higher)

I am still wrapping my head around projects vs. build configurations and when I should set up one vs the other. 

For now, I have moved all the VCS roots from sub-projects to a higher level in the project hierarchy (some all the way to the root project and others just high enough) so that they could be visible and attached to the "tagging build config" that I created (I'm calling it tagging because it's supposed to create Git tags, which are called Labels in TeamCity).

Regular build configurations run on agents. They take build queue time, they take time and resources on build agents. In exchange, they can also run build steps. Composite build configurations are just a way to aggregate results from the dependencies they are tied to and run some tasks that are server-side only, such as labeling, pinning, commit status publishing, etc. All those tasks happen on the server in regular builds as well, so this type of build allows the server to not require an agent to perform those tasks.

In TeamCity, the idea of a project is basically a hierarchy and configuration component. It allows you to structure your builds and set both shared configurations as well as restrict permissions. Build configurations are the components that actually define how builds should behave. When you have settings that want to be shared across multiple configurations, you want to set them at the project level, and at the project level where all the configurations that need that setting hang from (or you will need to have it duplicated with the issues of desync that that might cause).

In general, we structure components at the project or build configuration level based on our experience, our own requirements or from users. From those sources we understand that the need for some component is shared between multiple configurations (such as VCS Roots, or a connection to a docker repo) and then we add that to the project level, while others are specific to a build (such as labeling or reporting the status of the build), and the build configuration is just what defines what the build does.