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

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

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

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

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


tfs
person David W    schedule 16.01.2009    source источник
comment
Эта ссылка может быть вам. проверить. stackoverflow.com/questions/4990828/   -  person Sunil Agarwal    schedule 11.02.2012


Ответы (1)


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

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

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

person SqlRyan    schedule 19.01.2009
comment
Прости. Существует базовое предположение, что никто другой не фиксирует код до тех пор, пока сборка не завершится успешно, если только они не обязуются исправить сборку. Таким образом, любые последующие коммиты, которые по-прежнему приводят к неработающей сборке, не должны исправлять рабочий элемент неработающей сборки в TFS. - person David W; 04.02.2009
comment
Тогда не беспокойтесь - это на самом деле проще (пока предположение выполняется). Если процесс сборки завершается сбоем, он отправляет уведомление, а затем никакие другие уведомления не отправляются до тех пор, пока сборка не завершится успешно, когда процесс сбрасывается, а другая неудачная сборка приводит к новому уведомлению. Есть смысл? - person SqlRyan; 04.02.2009