Создавать рабочий элемент TFS только в новой неудачной сборке

Я видел пост об отключении создания рабочего элемента во всех неудачных сборках, но я бы хотел, чтобы TFS создавал рабочий элемент только при первом сбое. У нас очень сложная унаследованная система, которая включает в себя COM-компоненты VB6 и часто имеет сбои сборки на сервере сборки, которые отслеживают некоторую функциональность, которую VB6 делает с двоичными файлами (frx, ctl и т. Д.), Если вам не приходилось иметь дело с что через некоторое время ты не хочешь). Единственный способ решить эти проблемы - попытаться сделать обновления на компьютере разработчика, затем проверить файлы и снова запустить сборку (так как сборка не завершается неудачей на компьютере разработчика). Таким образом, у нас может быть три или четыре (или более) неудачных сборки, прежде чем мы добьемся успеха, что означает, что у нас будет три или четыре рабочих элемента для закрытия.

В идеале я хотел бы иметь следующее:

  1. Джо проверяет изменение, которое приводит к сбою сборки
  2. Рабочий элемент создается и назначается Джо
  3. Джо проверяет другое изменение, и сборка все еще не удается
  4. Нет необходимости создавать дополнительные рабочие элементы
  5. Джо проверяет изменения сборки успешно
  6. Рабочий элемент, назначенный Джо на шаге 2 выше, помечается как Закрытый

Но я был бы счастлив только с шагами с 1 по 4.

3 tfs
16.01.2009 14:34:19
Эта ссылка может вам. проверять, выписываться. stackoverflow.com/questions/4990828/…
Sunil Agarwal 11.02.2012 06:29:31
1 ОТВЕТ

Как бы вы определили, что вторая неудачная сборка была связана с первой, так как здесь требуется дополнительная регистрация? Что произойдет, если следующая регистрация на самом деле представляет собой дополнительный код, совершенный другим разработчиком - вы хотите, чтобы они знали, что их код нарушил сборку, или что он все еще не работает, даже если в соответствии с вашими действиями ничего не сработает.

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

Это двигает вас в правильном направлении?

1
19.01.2009 15:41:00
Сожалею. Существует основополагающее предположение, что никто больше не фиксирует код до тех пор, пока сборка не будет успешной, если только они не исправят сборку. Поэтому любые последующие коммиты, которые все еще приводят к поломке сборки, не должны получать рабочий элемент «исправить сломанную сборку» в TFS.
David W 4.02.2009 15:36:18
Тогда не стоит беспокоиться - это на самом деле проще (до тех пор, пока предположение верно). Если процесс сборки завершается неудачно, он отправляет уведомление, а затем никакие другие уведомления не отправляются до тех пор, пока сборка не завершится успешно, когда процесс сбрасывается, а другая неудачная сборка приводит к новому уведомлению. Есть смысл?
SqlRyan 4.02.2009 16:06:41