GitLab integration - building specific branches

Hi,

If the VCS specification only has that line, then it shouldn't build anything else (and the default branch). The branches to build are also configured in the VCS Trigger, not just the VCS Root. In the trigger, you can filter in or out some of the branches, using the branch filter: https://confluence.jetbrains.com/display/TCD10/Configuring+VCS+Triggers

How have you configured the triggers? Could you share screenshots with it? Did you do it via webhooks instead?

Apologies, but the setup was done by someone who is no longer on our team, so my information may be incomplete as I have no previous experience with TeamCity.

The trigger/hook is defined in GitLab (per repository) as follows:
(the TeamCity URL is just the main URL for TeamCity, and the "Build type" points to the "Build configuration ID" for the project in TeamCity)

In TeamCity the trigger has been simply disabled...
I've tried editing the "Branch specification" in the VCS root, but it seems to be ignored. I guess this is only in use if the trigger is defined in TeamCity?

After looking at the build logs, it turns out that even it says e.g. "develop" branch in the overview, it is actually checking out the master branch and building that.
In other words; any push to any branch will build master.

Hi John,

The branch specification only indicates teamcity which branches to track, it has nothing to do with which branches will be built. That depends on whatever is triggering the build. In your case, it's gitlab triggering them, so I think you would need to contact them to understand why it's triggering those builds in default instead of their own branch. You mention that the build logs say "develop". Where does it show that?

Okay, so the filtering basically has to be set in Gitlab then...

Here's a screenshot of the project history (where it looks like it's building feature and develop branches):

But when looking at the build log for one of these, it looks to me like it's fetching the master branch:

Hmm.. it seems this branch is collected by the GitLab integration. The integration is open source, so I had a quick look at the code:

branch = Gitlab::Git.ref_name(data[:ref])

HTTParty.post(
 build_url('httpAuth/app/rest/buildQueue'),
 body: "<build branchName=\"#{branch}\">"\
 "<buildType id=\"#{build_type}\"/>"\
 '</build>',
 headers: { 'Content-type' => 'application/xml' },
 basic_auth: auth
 )

Url to TC integration: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/models/project_services/teamcity_service.rb

I don't see why you think it's picking up the master branch in your repository. Is it because the "#master" at the end of the description? If that's the case, you can access the Description of the VCS Root configuration, and you will find that it's part of it. Can you verify whether the code/files pulled from the repository actually match the master or feature branches?

If you expand the "Compute revision for "<name>"" bit, you can find the revision that was used, and check whether it matches the branch revision or a revision in master.

1. Added a class/file to a test branch (tc-test), commited and pushed to GitLab.
2. TeamCity started building branch "tc-test" (which is displayed in Overview for the build).
3. Checked Computed revision:

Upper limit revision: 89d707ea4d38064a186e8d9cb116d47c80e2d169
Latest commit attached to build configuration: 89d707ea4d38064a186e8d9cb116d47c80e2d169
Computed revision: 89d707ea4d38064a186e8d9cb116d47c80e2d169

89d707ea matches the latest commit to the master branch.

4. Also checked Code inspection to see if my freshly added class/file was checked, which it was not.

It seems that TeamCity is given information on which branch the git push is done to, but still checks out the master branch.
I assume the branch name is given to TeamCity by the GitLab trigger as shown in the code in the previous post?

branch = Gitlab::Git.ref_name(data[:ref])

So I assume that TeamCity was given the branch name "tc-test" by GitLab?
Could there be something in the TeamCity config somewhere, global or project wise, that overrides what GitLab tells it?

Did another test, and added this to the branch specification for the project:

+:refs/heads/tc-test

This had no effect, and it still did a checkout of master/commit 89d707ea when pushing to the branch tc-test.

Hi John,

adding the branches that you want to build on to the branch specification is required, otherwise, teamcity doesn't have access to those branches, and builds that are triggered will not find a match and fall back to the default branch. The XML from the request looks correct and I have tested that a request with a tracked branch works.

If you simply added the tc-test branch and instantly triggered the build, teamcity hadn't had access to it yet, you would need to wait until teamcity starts having access to it before builds on it are able to access it (the waiting time shouldn't be longer than the poll period that you have configured.

Could you double check whether teamcity shows "tc-test" as a possible branch for the configuration, and whether triggering a build on it works after teamcity is tracking it?

If it still doesn't work, could you please send us a full build log (access the build log and click on "download full build log" and a screenshot of the change list for the build using the Submit a Request button above? It's sent through a private system, but feel free to redact any private information that you don't want to share with us.

Okay! One step further - thank you Denis!

I tried leaving the following branch specification in for a longer period:

+:refs/heads/tc-test

However; it still checked out the master commit (89d707ea) 

But when I changed it to:

+:refs/heads/*

It checked out and built the correct commit! :)

One last question though, is there a way to make it stop building default/master if it can't access the branch?
E.g. now when I deleted the tc-test branch, this triggered a new build, which then checked out and built master since it couldn't find tc-test anymore.

Glad to hear that you managed to make it work, although it's strange that tc-test doesn't work while * does. It looks to me like there is an issue with detecting the branch name in that case. I will pass it along in case there is something I'm missing.

Regarding your other question, yes, since 2017.1 it is possible to exclude the default branch from building entirely: https://confluence.jetbrains.com/display/TCD10/Configuring+VCS+Settings#ConfiguringVCSSettings-DisableBuildinginDefaultBranch

Could you please if teamcity-server.logs contains any entries with add2Queue in them? If so, what branch is specified there?

Denis: Okay, thanks a lot! We'll be looking to upgrade very soon then!

Dmitry: No, no reference to 'add2Queue' in any of the teamcity-server.log files

I think the following happens. TeamCity expects a logical branch name in the request sent by Gitlab. Gitlab sends a part of the full branch name starting after refs/heads. For it to work you need to use a branch specification like +:refs/heads/*, or +:refs/heads/(release-*), or +:refs/heads/(tc-test). In this case a logical branch name will match the branch sent by Gitlab and build will use a correct revision.