TeamCity и ожидающая фиксация ветки Git merge продолжают сборку с неудачными тестами - PullRequest
Новая
       11

TeamCity и ожидающая фиксация ветки Git merge продолжают сборку с неудачными тестами

2 голосов
/ 01 апреля 2010

Мы используем TeamCity для непрерывной интеграции и Git для контроля версий. В целом, это работает довольно хорошо - удобно, современно и дает нам быструю обратную связь, когда тесты не пройдены.

Есть странное поведение, связанное со спецификой слияния Git. Вот шаги кейса:

  1. Первый разработчик вытаскивает из мастер-репо.
  2. Второй разработчик вытаскивает из мастер-репо.
  3. Первый разработчик делает коммит А локально.
  4. Второй разработчик делает коммит B локально;
  5. Второй разработчик нажимает коммит B.
  6. Первый разработчик хочет выдать коммит А, но не может, потому что он должен сначала вывести коммит B.
  7. Первое извлечение разработчика из удаленного хранилища.
  8. Первый разработчик отправляет коммит A и генерирует коммит ветви слияния.

История коммитов в мастер-репо следующая:

  • B, второй разработчик
  • Первый разработчик
  • ветка слияния первого разработчика.

Теперь давайте предположим, что Second Developer исправил несколько неудачных тестов в своем коммите B.

TeamCity сделает следующее:

  1. Приходит коммит B - TeamCity делает сборку # 1 со всеми пройденными тестами

  2. Прибывает коммит A - TeamCity делает сборку № 2 (без коммита B), индикатор становится красным!

  3. TeamCity считает, что ожидающий коммит "Merge Branch" не содержит никаких изменений (каких-либо новых файлов) - но на самом деле он содержит слияние коммита B, поэтому TeamCity не хочет делать новую сборку и сделайте тесты зелеными.

Вот две проблемы: 1. В нашем случае мы провалили тесты, возвращающиеся во второй коммит (коммит А) 2. TeamCity не хочет делать новую сборку и делать тесты зелеными.

Кто-нибудь знает, как решить обе эти проблемы.

Я считаю разумным общий подход.

Ответы [ 2 ]

1 голос
/ 24 августа 2010

Просто добавлю, я настоятельно советую использовать git pull --rebase или просто выполнить git fetch, а затем выполнить ревизию того, что изменилось с помощью git log -p ^ master origin / master, чтобы определить, в порядке ли я с тем, что произошло из-за работы других разработчиков. На данный момент я могу переназначить свою работу поверх удаленных изменений, и teamcity не доставит вам проблем, которые вы видите здесь. Это не то, что я делаю, чтобы обойти Teamcity, но это также часть рабочего процесса, который позволяет более линейную историю и разрешать конфликты слиянием, к которым вам не нужно возвращаться при слиянии предыдущих слияний.

НТН,

Адам

0 голосов
/ 15 апреля 2010

Еще не исправлено в 5.0.3. Но сообщается как известная проблема

Вы можете проголосовать за этот вопрос на http://youtrack.jetbrains.net/issue/TW-9584

...