Интеграция GitLab с TeamCity

Так как GitLab 7.6 или около того есть новый вариант использования TeamCity непосредственно из проектов GitLab. В настройке есть это сообщение:

Конфигурация сборки в Teamcity должна использовать номер формата сборки % build.vcs.number%, вы также захотите настроить мониторинг всех ветки, поэтому сбор запросов слияния, этот параметр находится в корневом каталоге vsc расширенные настройки.

Я не уверен, как это работает. Допустим, у меня есть репозиторий Foo.

У меня есть настройка TeamCity для прослушивания Foo с указанием ветки: +:refs/pull/*/merge

Затем я вывожу Foo в gitlab как FooFork, вношу изменения, затем запрашиваю слияние FooFork → Foo.

Но ничего не происходит, чтобы проверить это слияние, чего я ожидал от GitLab. Если я принимаю слияние, то сервер сборки переходит в действие (сразу) и строит дважды (master и /ref/master).

Я также установил конфигурацию сборки для использования точно:% build.vcs.number% как номер сборки, как указано, но gitlab, похоже, не дает мне никакой информации о результате сборки.

Итак, я немного смущен в отношении того, что именно должна делать эта интеграция GitLab → TeamCity, и я делаю неправильно.

В настоящее время я запускаю GitLab 7.9 и TeamCity 8.1.4

Обновление:

Кажется, этот вариант использования не поддерживался до версии 8 - https://github.com/gitlabhq/gitlabhq/issues/7240

Ответ 1

Я запускаю GitLab 8.0.2 и TeamCity 9.1.1 и могу запускать CI-сборки для веток и запросов на объединение.

Я запускаю сборки CI для определенных ветвей, устанавливая триггер VCS вместе с спецификацией отрасли +:refs/heads/(xyz*) где xyz - это строка для нашего билета системный префикс, так как все активные ветки должны быть названы после записи в нашем отслеживателе проблем.

Я запускаю сборки для запросов слияния через спецификацию ветки +:refs/(merge-requests/*)

Все работает так, как ожидалось, и позволяет нам знать статус всех ветвей функций/ошибок и автоматически выполнять запросы слияния.

Благодаря комментарию Роба, связанному с записью заметок GitLab 8 в спецификации запроса слияния.

Ответ 2

Такая же проблема. Может быть, другой способ, я сейчас оцениваю. Поскольку нет прямого способа получить объединенное состояние от целевого MR, вы должны создать его самостоятельно:

ИМО там следующие todos
1.) начать голый репо $ git init
2.) добавить целевое репо $ git remote add origin [email protected]:<origin.group>/<origin.repo>.git
3.) добавьте удаленный /feature/to -merge $ git remote add target [email protected]:<feature.group>/<feature.repo>.git
4.) проверить свою ветку функций $ git checkout -b <feature.branch> feature/<feature.branch>
5.) проверить свою оригинальную ветку $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Функция пересылки в исходную ветвь $ git rebase <feature.branch>

Как указано здесь [1], GitLab-CE может запустить событие при создании запроса на слияние,

так что все, что вам нужно сделать, это создать мета файл, который может оценить WebHooks.

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