Мы используем TeamCity и GitHub Enterprise. Мы используем рабочий процесс с открытым исходным кодом с git: существует репозиторий mainline для каждого компонента, и когда люди хотят внести изменения, они
- fork
mainlineв свою учетную запись (так что может быть много вилок) - создать ветку в своей вилке
- осуществить изменение
- обновить с помощью
mainline/masterизменения, которые произошли за это время - отправить запрос на перенос
fork/feature-branch→mainline/master
Мы очень довольны этим документооборотом; он заставляет проверять код (ну, по крайней мере, ручной шаг, который, надеюсь, включает в себя собственно чтение кода и выполнение его тестов), прежде чем mainline увидит любые изменения, которые исторически были проблемой. Мы хотели бы использовать GH Status API (сообщение в блоге, API doc), чтобы включить кнопку слияния не зеленый, если автор является лицом, смотрящим на запрос pull-request, но для более позднего.
У нас есть TeamCity 7.1, настроенный для просмотра репозиториев mainline и сборки при изменении изменений. Тем не менее, способ, которым он в настоящее время настроен, CI строится только тогда, когда он видит изменения в mainline/master.
Как нам настроить наши корни VCS в TeamCity, чтобы мы могли иметь один и тот же рабочий процесс, но CI запускает сборку на основе ветвей в вилках ретрансляции mainline?. Желательно, чтобы мы не регистрировались каждая вилка индивидуально?
Я прочитал документацию о функциональных подразделениях TeamCity 7.1 (сообщение в блоге, примечания к выпуску, , но я не вижу, как применить его к нашей модели произвольных чисел forks, в отличие от всех - commits-to-mainline-in-feature -branches.