Как настроить закрытую регистрацию для ветки

Question

У меня есть два определения сборки для моего проекта, который имеет две ветви. Развитие и Live.

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

Тем не менее, мои настройки запускаются каждый раз, когда разработчики также работают над веткой разработки.

Есть что-нибудь, что я делаю не так?

Макет моего проекта:

 $/KCTC/Lib/         (Contains all referenced dlls)    
 $/KCTC/Projects/    (contains branches)
 $/KCTC/Projects/Development
 $/KCTC/Projects/Live

Как только ветка не видит файлы, на которые ссылается Lib:

Рассмотренный "........ \ Lib \ fluentnhibernate-NH3.1-1.2 \ Iesi.Collections.dll", но его не было.

Настройка моей live gated сборки: Также у меня есть модульный тест, созданный в NUnit в проекте, и это не удается, потому что

Запросы \ StarMetrics \ 20110613 \ StageTestSuite.cs (2): тип или имя пространства имен 'NUnit' не найдено (вы не используете директива или ссылка на сборку?)

определение рабочего пространства:

и мой процесс определения

Answer 1

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

$/KCTC/Projects/    (contains branches) <-- remove this
$/KCTC/Projects/Development <-- remove this as well
$/KCTC/Projects/Live  <-- this should contain everything you need for the Live branch correct?

, что в основном гласит: «выполнять закрытые проверки для всего, что содержится в этой папке» ... Вам нужно удалить указанную строку, чтобы убедиться, что вы не запускаете проверенные проверкиins при проверке кода из ветви разработки или родительской папки, содержащей все ветви.

Что касается отсутствующих двоичных файлов Lib, могу поспорить, что относительный путь немного отличается.Я бы проверил физически на сборочной машине, чтобы подтвердить.

Answer 2

Ладно, и решения:

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

ПРИМЕЧАНИЕ если у вас несколько dll с одинаковым именем, вы получите ошибку в tfs (это не повлияет на сборку, но ее ошибка)

Или альтернативой является добавление dll, необходимых для проекта, в ресурсы сборки.

Answer 3

На скриншоте определения рабочей области вы видите, что вы нарушаете относительные пути на сервере сборки, добавив "\ Moose" в папку агента сборки.

Вы хотите:

$ / KCTC / Lib | $ (SourceDir) \ Lib
$ / KCTC / Проекты / Live | $ (SourceDir) \ Проекты \ Живая