2013-10-01 2 views
17

Мы используем GitLab для управления нашими репозиториями. Мы пытаемся следить за процессами GitFlow, и в рамках этого мы хотели бы иметь возможность автоматически создавать и выполнять тесты по любому запросу слияния в TeamCity.Gitlab - запросы на слияние зданий на сервере CI

Из того, что я вижу, это возможно в GitLab CI, но переход к этому не является реалистичным вариантом для нас.

Я видел учебники о достижении этого на GitHUB с использованием спецификации ветки, например, + refs/pull/*/merge. Создается ли подобная спецификация ветки GitLAB?

Мы используем версию 4.2 GitLab но может обновить, если требуется для этой функции и версии 8 TeamCity

+2

Я думаю, что это было бы очень полезно. Для Jenkins доступен построитель запросов слияния, но я не могу найти эквивалент для TeamCity (https://github.com/jenkinsci/gitlab-merge-request-builder-plugin). Глядя на источник этого плагина, он предположил, что он намного сложнее, чем просто смотреть что-то вроде + refs/pull/*/merge. –

ответ

10

У меня есть GitLab 6,3 и TeamCity 8 и мне нужно построить полнометражных ветви тоже. У нас есть рабочий процесс (он основан на потоке git, но немного изменился в соответствии с нашим циклом выпуска).

Итак, у нас есть development ветка и одна кнопка для перехода с определенным именем dev/feature-name-here.

Далее, создавая запрос слияния в GitLab от dev/feature-name-here до development.

TeamCity настроен на автоматический запуск сборщиков для каждой ветви с помощью следующего refspec: +:refs/heads/dev/(*), чтобы мы могли видеть, что сборка для ветки feature-name-here автоматически запускается.

Далее у меня есть собственный скрипт, который встроен в страницу запроса слияния GitLab. Он делает следующее.

  1. Обнаруживает ветвь исходной и целевой, глядя на MR странице
  2. С TeamCity REST API перебирает построить который принадлежит к целевой ветви (в TeamCity 8 можно назначить пользовательский построить идентификатор конфигурации для построения так мы используем некоторые семантические имена, такие как devUnit, devIntegration, devWhatever и т. д.)
  3. Создает таблицу, содержащую изображения статуса сборки для ветвей источника и цели для каждой связанной конфигурации сборки.

Теперь это выглядит следующим образом:

TC Build status at GitLab

Сейчас этот подход имеет некоторые недостатки, например, если один обновляет ветку с другим толчке я не могу понять из GitLab странице новые коммиты уже или мне нужен старый статус сборки, поэтому мне нужно щелкнуть ссылку на сборку и проверить в TeamCity

+0

У меня есть эта настройка для создания запросов на слияние для master. Мы создаем горячие исправления с именем «hf/». Teamcity собирает филиалы, но это не автообработка. Есть ли какие-либо конкретные настройки в триггере сборки? – Broncha

+0

Мы ничего особенного не делаем, кроме стандартных триггеров сборки vcs. Они настроены без каких-либо фильтров и исключений - только начинаются, если обнаружены изменения. – Olegas

+0

Привет @Olegas, где я могу получить дополнительную информацию о том, как вы это достигаете? –

Смежные вопросы