How to configure VCS settings for a build configuration that builds GitLab merge requests only?

I want to trigger a specific TeamCity (2018.2.4) build when GitLab (Community 11) merge requests are created and pushed but not when any other branch is pushed (for other branches I'll have different build configs).

Here's what I have done:

In GitLab, I enabled Integrations -> JetBrains TeamCity CI and filled in my TeamCity access data and Activated the configuration. Hit the Test & save button, the test succeeded

In TeamCity:

- first, I don't wan't to build for polled changes every minute, so I opened Triggers and disabled the default VCS trigger there

- second, I don't want to run builds in default branches (not sure what do they mean in merge-request context), so I went to VCS Roots and in Default Branch Settings unchecked "Allow builds in the default branch" (as the help hint there also says I might want to disable this for pull requests)

- third, I opened the VCS Root and attempted the following refspecs in Branch specification:

1) this one is directly from GitLab manual for fetching merge requests:

+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*

TeamCity didn't accept it because it has two * in it. So I shortened it and also added () around to capture more of the branch name for displaying in the UI:

+refs/(merge-requests/*)/head

Maybe I needed : in front? not sure. Some examples use +: and some just +.

This one was accepted by TeamCity.

I left Default branch as refs/heads/master, since it presumably won't be used anyway because I unchecked that "Allow builds in the default branch" checkbox, right?

Not sure about Changes Checking Interval - I will trigger the build from GitLab, so why TeamCity wants still to poll something?

Also went to Build Features and added Commit status publisher, Publisher: GitLab, filled in my access token and GitLab API URL, hit Test connection - it worked.

Finally, I triggered the build by pushing a commit to GitLab to a test feature branch named feat_1 which was related to an existing merge request #5, also visible in TeamCity as a branch merge-requests/5

But the build failed with a message:

Failed to start build #3 in branch feat_1 at 22 May 19 18:52 on Default Agent
Failed to collect changes, error: Builds in default branch are disabled in build configuration

The full log is

[18:52:15][Collecting changes in 1 VCS root] VCS Root details
[18:52:15][VCS Root details] "mygiturl.git#refs/heads/master" {instance id=1, parent internal id=2, parent id=BuildMergeRequests_GitmygiturlGitRefsHeadsM, description: "mygiturl.git#refs/heads/master"}

I'm not sure why it even tries to collect changes in the default feat_1 branch at all instead of collecting the changes in merge-requests/5 branch?

 

Also, when I created a new merge request in GitLab, the build in TeamCity was not triggered at all. Not sure, who's to blame - the GitLab side with its TeamCity plugin or my failed attempts to adjust refspecs.

I might want to use GitLab webhooks, but not sure how to attach them to TeamCity (most probably, TeamCity won't see the calls at all; but with Jenkins it seemed to work fine).

 

How do I configure it to do what I want and pull and build only merge-requests/5 changes when build is triggered by GitLab callback?

0
2 comments
Avatar
Permanently deleted user

It seems I got it right.

At first, it seems TeamCity plugin in GitLab is not good for merge requests because it causes the TeamCity trigger to receive the branch name that is not in merge-requests ref spec filter. Thus it causes building attempt in a wrong branch and shows the error.

So, I disabled the TeamCity plugin in GitLab and got rid of the error. But then, of course, my builds weren't triggered anymore after pushes to merge branches. So I had to enable the Trigger in TeamCity, and it started working correctly. It works with some delay, though, but it's acceptable.

Also the integration back from TeamCity works OK marking the GitLab pipeline status as Success with a link to TeamCity. Although I expected it to work more like Jenkins adding comments with badges for merge requests.

 

Also, I'm afraid that with time my TeamCity branch list will get cluttered with hundreds of merge request branches. Not sure, how to clean them up - I guess, it's all or nothing, based on the VCS Root filter.

0

Yes, I think I also need to be like Jenkins. Because it is no delayed, There is no way to achieve this function.

0

Please sign in to leave a comment.