Как сообщить TeamCity относиться к слияниям как к одиночной фиксации при работе с git?

Недавно мы перешли из SVN в git. Мы работаем с основной ветвью "выпуска" (master) и ветвями функций для каждой функции, над которой работает разработчик. В TeamCity у нас есть проект для каждой ветки функций и, конечно, проект для мастера.

Когда мы работали с SVN, всякий раз, когда кто-то сливался с мастером в свою функциональную ветку или наоборот, слияние было обработано TeamCity как одно коммит. Теперь, при git, каждое слияние заставляет TeamCity показывать все коммиты, которые пришли с этим слиянием.

Это приводит к некоторым проблемам, например, когда кто-то сливается с мастером в свою ветку функций, и теперь его проект TeamCity показывает "283 ожидающих изменения" из-за этого слияния, если сборка завершилась неудачей, авторы этих изменений будут уведомлены, так как если они вносили изменения в ветвь функции.

Есть ли способ сказать TeamCity относиться к git слияниям как к одиночной фиксации?

Мы могли бы решить это, используя сжатые слияния, но это то, что мы действительно хотели бы избежать.

Ответ 1

Это два возможных решения:

Один из способов решить эту проблему (хотя, возможно, очень неудобно, в зависимости от вашей ситуации) состоит в том, чтобы уведомлять пользователей о уровне конфигурации сборки, а не об уведомлении, кто совершил/был объединен. Создайте отдельные конфигурации сборки для разных ветвей разделов и настройте уведомление для каждой конфигурации сборки, чтобы уведомлять только "владельца" ветки темы.
Меньше уверен, но стоит попробовать: вы можете настроить уведомление для каждой ветки темы, например. по шаблонам подстановок на пути к ветке. Это должно быть возможно с помощью подключаемого модуля пользовательского уведомителя DYI, который использует, например, свойство имени ветки, teamcity.build.vcs.branch. <my_vcs_name > .

Конкретное ограничение уведомления электронной почты TeamCity (его легко поддерживать) заключается в том, что вы не можете фильтровать уведомления с помощью комбинации конфигурации сборки и "Игнорировать сбои, не вызванные моими изменениями". По крайней мере, вы могли бы сконфигурировать сборку для основной ветки, чтобы уведомляли коммиттеров и создавали конкретные настройки только для проектов ветвей темы.

Ответ 2

Я уверен, что это та же проблема, что у нас были несколько дней назад, но наоборот. Мы объединили ветвь dev в master, что заставило TC попытаться построить каждую регистрацию, которая была частью слияния. Очевидно, не то, что мы хотели.

Чтобы исправить это, не сохраняйте параметр Trigger build on each check-in в Build Trigger.

Вы получаете полную историю изменений из ветки источника, но TeamCity будет только строить ветку назначения, используя последний объединенный код. Если эта сборка завершилась неудачно, слияние должно быть единственным уведомленным.

Ответ 3

Это длинный снимок, и вы, вероятно, уже пробовали его, но может ли он работать с параметром триггера per check-in на Include several check-ins in build if they are from the same committer? Этого может быть достаточно, чтобы обмануть ТС для создания коммитов в виде единого пакета.