Suppose you have project A and project B, where project B depends on project A - let's say A is a library. And project A and project B live in separate version control repositories - either because project A was created by a third party, or because you just decided to organise your repositories that way. You want to make some changes to project B, but in order to do so you have to make some changes to project A. So you make two pull requests, one for your changes to project B and one for your changes to project A - these PRs "have to" be applied together - although in practice, of course, one of them has to be merged first (logically, it has to be the PR for project A) and here's where the problem can come in.
We have our CI server (TeamCity) set up to build all feature branches, so we can easily see if an individual, standalone PR to project B breaks things in project B. But because code in feature branches doesn't get published to our artifact repository (Nexus) until it's merged to master, this doesn't work so well for pairs (or even chains) of PRs like the scenario described above. We can only see, in a valid way, if the PR for project B is going to build on the build server after we've already merged the PR for project A. And it just so happened recently that this dependent build failed... because of a problem that only occurred on the build server.
Thus, we ended up with a situation where project B's master wasn't building due to a tightly-bound pair of PRs only being half-merged - the PR for project A had been merged, but the PR for project B hadn't been yet, due to the unexpected issue on the build server.
How could we adjust our workflow to avoid this kind of problem in future?