2016-07-27 2 views
2

Мы строим функции в ветвях GitHub (одна ветвь для одной функции). У нас есть филиал разработки и ведущая отрасль. Оба всегда должны быть зелеными.Триггер TeamCity по запросу Pull против триггера при объединении

Мы используем TeamCity для сборки и развертывания. То, что я хочу получить, заключается в том, что при создании запроса на перенос (из ветки функции для разработки) TeamCity автоматически создает и тестирует запрос, а затем загружает экземпляр EC2, чтобы его можно было вручную протестировать. Когда запрос на извлечение затем объединяется, TeamCity собирает, тестирует и создает изображение докера, которое мы выталкиваем на ECS.

Это все работает, за исключением того, что мы запускаем неправильно.

1) Для построения запроса на растяжение корень VCS имеет по умолчанию ветвь, установленную как develop, и имеет спецификацию ветвления +:refs/pull/(*/merge) - мы не хотим только строить запрос на растяжение, а строить объединенный код. Затем мы развертываем это на экземпляр EC2 для ручного тестирования.

2) TeamCity сообщает о статусе построения запроса на вытягивание в GitHub и после ручного тестирования с использованием экземпляра EC2 код объединяется с ветки функций в разработку. На этом этапе мы хотим построить код в разработке, а затем мы выталкиваем новый микросервис на Amazon ECS. Для построения после того, как запрос на растяжение объединяется в разработку, корень VCS имеет набор по умолчанию, заданный как develop.

В действительности 1 всегда срабатывает, например. как для поднятия запроса на растяжение, так и для слияния. 2 запускается только тогда, когда происходит слияние в развитие, что является правильным.

Любая помощь была бы принята с благодарностью.

EDIT

Я разъяснила две конфигурации сборки мы используем выше

+0

Как вы описали это, это звучит так, как будто есть два корня VCS, или вы пытаетесь динамически установить ветвь по умолчанию (может быть, как я это интерпретировал) Можете ли вы подтвердить, что у вас есть только один корень VCS, и вы не изменяете динамические параметры по умолчанию/ветви. –

+1

У нас есть два корня VCS для проекта, один корень VCS для каждой из конфигураций сборки. Мы не меняем спецификации по умолчанию или ветви динамически, просто мы установили два корня VCS по-разному. – christophmccann

+0

Aha - Я бы поставил под сомнение необходимость в двух корнях VCS, поскольку это должно сработать с одним - Вы хотели поболтать об этом? http://chat.stackoverflow.com/rooms/117201/evolve-software-ltd –

ответ

0

Я согласен с Evolve Software Ltd, что вы, вероятно, может решить все конфигурации сборки нужно с одного корня VCS. Я не понимаю, что не так со сценарием 1, но подразумевается, что вы не хотите создавать слияния для разработки там. Я думаю, что вы ищете подходящую спецификацию Фильтра-фильтра в вашем VCS Trigger для соответствующих конфигураций сборки. Синтаксис довольно прост и TC документы охватывают эту часть, если я неясно:

  • +:<default> будет включать в себя ветвь по умолчанию (как указано в VCS корень)
  • -:<default> исключит ветвь по умолчанию
  • + or -:branch_name будет включать в себя или исключить имя логической ветви, указанное в спецификации филиала (часть в parens или все, если нет парнеров)

Обратите внимание, что если вы укажете запись «исключить», вам нужно указать запись «включить», хорошо, даже если просто +: *, и вы можете указать столько записей, сколько необходимо (в разных строках).

Надеюсь, это поможет.

1

Согласно документации, если вы хотите только создать объединенный код вашего запроса на тяну, вам не нужно указывать скобки.

https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/

Теперь, (...) см, был ли конкретный запрос результат слияния или только самой отрасли. Для этого мы можем указать следующие данные в спецификации Branch

+: рефы/тянуть/(*/слияние)

После запроса тягового создан, TeamCity будет только проверить результат объединенного кода в развиваться.

Использование Teamcity automatic merge функции (входит в TC9), новое обязательство будет срабатывать на develop ветвь, которая будет запускать конфигурацию (построить на разработку, испытания на разработку, развертывание ...) правильно

Таким образом, вам просто нужно заменить спецификацию вашего филиала: +:refs/pull/(*/merge) на +:refs/pull/*/merge

+0

Я сделал это - теперь у меня есть один мониторинг корневого VCS, а затем в спецификации ветки есть: refs/pull/*/merge. Это, очевидно, запускает обе конфигурации сборки, поэтому я попытался добавить фильтр ветвления к триггеру с помощью:: refs/pull/*/merge - но это предотвращает его запуск по новому запросу на pull. Есть идеи? – christophmccann

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