How to build dependency only if it has relevant changes?

I do not work for Jet Brains, but I am using Snapshot Dependencies with TeamCity. I do not think it is possible from my experience and the documentation https://confluence.jetbrains.com/display/TCD10/Dependent+Build . 

My reading of the main purpose of Snapshot Dependencies is to have build configurations work together on the same source. TeamCity thinks the "same source" means the same VCS check-in, if the build configurations use the same VCS root, as in your case. If the build configurations have different VCS roots, there is a very good rule that works very well in my experience. 

I suspect from your project A and project B descriptions that they can run independently if both projects are OK.  Thus I think you could remove snapshot dependency and have things work if project B is taking up too much build server time, though things will get a little noisy is a commit to AppDependencies breaks both projects. 

Hope this helps.

--

Chris

Thank you, Chris, what you say describes my case and thoughts correctly.

So at the moment, I have two projects in TC, and they run and fail independently, thus as a developer I have to manually make sure that on a particular PR all projects succeeded. So at the moment if project A succeeded but tests on project B failed my PR should not be merged. 

If you just want to make sure that the PR (pull request?) is  automatically merged correctly, in this case you should look at Composite Build Configurations https://confluence.jetbrains.com/display/TCD10/Composite+Build+Configuration  so your merging build config / project C depends on both A and B, runs when both are passing. This is a new in 2017.2 feature. 

Good luck.

Hi Bondan and Chris,

thanks for the discussion, and sorry for the delay. I'll try to bring a bit of official info into snapshot dependencies:
-Snapshot dependencies establish dependency relations. If project B should not be triggered on project A, then they aren't dependent, even if they share the same root.
-Snapshot dependencies main goal isn't sharing source. You can have a chain of 10 builds and have a different set of sources for each and it's all fine. If some builds happen to share some of the sources, then the revision will be maintained for consistency, and while this is a very much intended part of the feature, it's not the main goal of snapshot dependencies. Ordering of dependent builds is. A classic example of a dependency is a build that builds an artifact, and a build that deploys it somewhere. As the second build requires explicitly the first (without an artifact there is nothing to deploy)
-If you share configuration, be it VCS Roots or parameters, then the idea is to have them hang from the same project. You can define the VCS Root and parameters at the project level, and simply reuse them in both build configurations. That way, you don't duplicate information and keep separate builds separate.
-If you share a lot of configuration between the two build configurations, you can define a build template and simply have both builds inherit from that template, then add the differentiating elements to the specific builds, while all the shared information is stored in the template.

Hope this helps.

Thank you, Denis and Chris. 

What you said confirmed my understanding of the topic.

Just to recap, I plan to proceed with having one job for building both projects.

If it becomes my bottleneck, I will consider using some build optimization tools like Facebook's Buck.