Ответ 1
У меня есть GitLab 6.3 и TeamCity 8, и мне также нужны встроенные ветки функций. У нас есть рабочий процесс (он основан на git -flow, но немного изменен в соответствии с нашим циклом выпуска).
Итак, у нас есть ветвь development
и одна нажимает ветвь функции с определенным именем dev/feature-name-here
.
Затем создадим запрос на объединение в GitLab от dev/feature-name-here
до development
.
TeamCity настроен для автоматического запуска сборников для каждой ветки со следующим refspec: +:refs/heads/dev/(*)
, чтобы мы могли автоматически запустить сборку для ветки feature-name-here
.
Затем у меня есть пользовательский script, который встроен в страницу запроса слияния GitLab. Он делает следующее.
- Обнаружение ветки источника и цели, просматривая страницу MR
- С API-интерфейсом TeamCity REST перечисляет сборку, которая принадлежит ветке-кандидату (в TeamCity 8 мы можем назначить индивидуальный идентификатор конфигурации сборки, чтобы мы использовали некоторые семантические имена, такие как
devUnit
,devIntegration
,devWhatever
и т.д...) - Создает таблицу, содержащую изображения статуса сборки для исходных и целевых ветвей для каждой связанной конфигурации сборки.
Теперь это выглядит так:
Теперь этот подход имеет некоторые недостатки, например, если вы обновляете ветку с другим нажатием, которое я не могу понять на странице GitLab, новые коммиты уже построены или я старую статус сборки, поэтому мне нужно щелкнуть по сборке ссылка и регистрация в TeamCity