Запуск недетерминированной сборки TeamCity с помощью Git

Я использую стратегию ветвления GitFlow. Мне нравится иметь 3 конфигурации сборки для каждого проекта:

  • Integration - builds from develop, feature/* and hotfix/* with branch specification
    • +:refs/heads/(develop)
    • +:refs/heads/feature/(*)
    • +:refs/heads/develop/(*)
    • +:рез/головы/(исправление/*)

  • Beta — сборка из beta/* со спецификацией ветки

    • +:refs/heads/(release/*)

  • Релиз - сборка из мастера со спецификацией ветки

    • +:refs/heads/(master)

Обратите внимание на использование квадратных скобок для установки моих предпочтительных имен ветвей. Причина, по которой у меня есть эти 3 сборки, заключается в том, что я использую имя конфигурации сборки как часть имени сборки, поэтому, например, я получаю сборки в формате 1.2.3-Integration.27, а последнее число «27» — это общий для всего проекта общий счетчик сборки. Я также выполняю различные действия после сборки в разных конфигурациях, например, конфигурация выпуска выполняет действия по развертыванию.

В качестве примера того, что я называю «недетерминизмом», я только что объединил функциональную ветку с помощью запроса на включение в разработку. Я получаю сборку в моей конфигурации сборки интеграции, которая создает ветку разработки. Но затем я также получаю сборки для двух других конфигураций сборки, хотя в спецификациях их веток ничего не изменилось; это определенно не то, что я хочу, потому что моя конфигурация выпуска, например, развертывает вещи. Вот снимок экрана с выделенными сборками-нарушителями: введите здесь описание изображения

Обновление — дополнительная информация Вот обзор "нарушающей сборки" введите здесь описание изображения А вот и конфигурация триггера введите здесь описание изображения

Я явно чего-то не понимаю в том, как TeamCity должен работать с Git. У меня сложилось впечатление, что конфигурации сборки предназначены только для создания вещей, подпадающих под их спецификацию Branch. Откуда берутся два других? Почему эти сборки запускаются, когда спецификация ветки не включает разработку (или refs/heads/develop)? Есть ли способ предотвратить это?

Я пытался поднять этот вопрос на форуме поддержки JetBrains, но, похоже, у меня не было там никакой поддержки, поэтому я решил обратиться к сообществу StackOverflow.


git git-flow teamcity buildconfiguration
person Tim Long    schedule 05.05.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

person Biswajit_86    schedule 05.05.2015
comment
Спасибо за ответ - отправили дополнительную информацию по запросу. Если я правильно вас понимаю, вы предлагаете мне указать ветки снова в триггере? Если да, то для чего нужна спецификация филиала? - person Tim Long; 05.05.2015
comment
Спецификации ветвей отлично подходят для переопределения соглашений об именах (например, изменения, которые вы сделали в скобках для выбора более коротких имен для ветвей). Когда дело доходит до спецификаций веток, есть некоторые подводные камни, и у меня есть собственные сомнения относительно того, что именно выбирается или фильтруется на вкладке спецификации веток (например, всегда выбирается ветка по умолчанию, develop). Однако спецификации триггера работают с точностью до точки и лучше подходят для выбора/фильтрации определенных ветвей. Не стесняйтесь отвечать, если я неясен - person Biswajit_86; 05.05.2015
comment
Я понимаю, что вы имеете в виду... Все мои конфигурации сборки наследуются от общего шаблона, и я стараюсь свести к минимуму различия между конфигурациями, я надеялся, что спецификации ветки будет достаточно. Я думаю, нет! Ну, небольшая цена, я полагаю, если сборка работает должным образом. Я немного поэкспериментировал с ним, и мой триггерный фильтр, похоже, не работает должным образом. Интересно, не могли бы вы привести пример фильтра триггера по сравнению со спецификацией ветвления из одной из ваших сборок? (Конечно, при необходимости анонимно). - person Tim Long; 06.05.2015
comment
Я целую вечность пытался заставить ТиСи подчиниться, но что бы я ни пытался, оно побеждало меня на каждом шагу. Например, если вы хотите установить фильтры ответвлений для триггера VC, вы не сможете сделать это как часть шаблона! В конце концов я отказался от фильтров ветвей в триггере и вернулся только к использованию спецификаций ветвей, которые я устанавливал в качестве параметра конфигурации в каждой из моих конфигураций сборки. Я обошел тот факт, что «разработка» (то есть ветвь по умолчанию) будет срабатывать везде, создав фиктивную ветку с именем NoBuild и сделав эту веткой по умолчанию. Гнусный хак, но работает. - person Tim Long; 07.05.2015