Integrating GitLab with TeamCity

问题:

Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:

The build configuration in Teamcity must use the build format number %build.vcs.number% you will also want to configure monitoring of all branches so merge requests build, that setting is in the vsc root advanced settings.

I'm not sure how this works. Lets say I have a repository Foo.

I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge

I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.

But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).

I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.

So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.

I'm currently running GitLab 7.9 and TeamCity 8.1.4

Update:

Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240

回答1:

I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.

I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.

I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)

Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.

Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.

回答2:

Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:

IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git@your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git@your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>

As stated here [1], GitLab-CE can fire an event on creation of a merge-request,

so all you have to do is building some meta, that can evaluate the WebHooks.

[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events