Multiple VCS roots: how to trigger against Merge/Pull Requests on EITHER root?

Hi - we have a TC project that uses multiple roots - let's call them A and B.  We then want to trigger a validation build if a Merge Request is made against either root.

(We use Gitlab, which uses "Merge Requests", as opposed to Github, which uses "Pull Requests", so I'll be using the term "Merge Requests" or MRs from here on out - but the basic question can apply to either.)

We use the Pull Requests build feature, because we want to only trigger against MR which are targeting certain branches to merge into.  For gitlab, this means it adds logical branch names that look like, ie, `merge-requests/57`.

The problem is that, if there is new commit in repo A for `merge-requests/57`, we want repo B to build using it's "default" branch.  However, because both repo A and repo B are Gitlab repo, and use the same numbered system for MRs, there is frequently ALSO a, completely unrelated, `merge-requests/57` logical branch name for repo B. TeamCity will then use that branch for repo B as well - resulting in a build which is not testing what we want to test, and frequently broken as well.

How can we trigger against MRs in either repo, but have the other repo always use it's default branch?  It seems like we need some way to add some extra prefix or suffix to the generated logical names - so, ie, we would end up with `repoA/merge-requests/57` - but there doesn't seem to be a way to do that.  Thanks!

Comment actions Permalink

Hi - noticed this post is still pending approval.  Is there a problem I can address? I wanted to reference this description of the issue in another place, but I can't link to it until it's been approved. Thanks!

Comment actions Permalink
Hi! We acknowledge that relying on refs like `merge-requests/57` when building pull requests is problematic. Addressing it is on our list:
In the meantime, the simplest workaround would be having multiple build configurations, one for triggering Merge Request builds in each attached repo. Such build configurations would only have the Pull Requests build feature configured for one VCS root, not both/all of them.
Comment actions Permalink

My setup already has multiple triggering build configurations, one for each repo:

                                       |                                     |
                                       | TriggerA Build Config               |
                                       |   vcsRootA                          |
                                       |      +:refs/(merge-requests/*)/head |
_______________________________________    /
|                                     |   /
| RealWork Build Config              |  /
|   vcsRootA                          | /
|      +:refs/(merge-requests/*)/head |/
|   vcsRootB                          |\
|      +:refs/(merge-requests/*)/head | \
|_____________________________________|  \
                                       |                                     |
                                       | TriggerB Build Config               |
                                       |   vcsRootB                          |
                                       |      +:refs/(merge-requests/*)/head |

The problem is that it still results in a `` which is, ie, `merge-requests/57`, which is still recognized as a valid logical branch name by both vcsRootA and vcsRootB when it comes time to run `RealWork`

Comment actions Permalink

The behavior I want is if TriggerA is run due to merge-requests/57 in from vcsRootA, I want:

RealWork Build Config
vcsRootA set to merge-requests/57
vcsRootB set to <default>

Please sign in to leave a comment.