Сборка vNext на TFS 2015 зависает на этапе MSBuild и не создает файлов журнала

Недавно мы обновили локальную версию TFS2013 до 2015 Update1 и настроили агент сборки VSO.

Сейчас я пытаюсь настроить тестовую (непрерывную интеграцию) сборку vNext для решения в нашем репозитории Git, но сборки не выполняются и не создают никаких журналов.

Свойства сборки были настроены для указания правильного репозитория Git, и следующие три были добавлены в переменные: VSO_GIT_USERNAME, VSO_GIT_PASSWORD, DNXPath. MSBuild - единственный шаг, добавленный в сборку в настоящее время.

Показан шаг MSBuild

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

Ожидание агента сборки

Кажется, с агентом все в порядке:

  • он отображается как работающий (проверено в services.msc)
  • у него нет SSL-зависимостей
  • порт 9191 был добавлен во входящие правила в брандмауэре сервера TFS
  • агент работает с правами «Project Collection Build Service»
  • агент отображается зеленым в веб-доступе:

введите здесь описание изображения

Когда я отменяю сборку и загружаю файлы журнала, zip-файл становится пустым.

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

Что мне делать / проверять, чтобы моя сборка продолжалась или создавались файлы журнала?

Кто-нибудь может предложить путь вперед?


git tfs continuous-integration build tfs-2015
person Victoria    schedule 30.03.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Хорошо, решение найдено! В моем конкретном случае я настроил порт 9191 с помощью интерфейса брандмауэра (Windows Server 2012 R2), и входящее правило для него выглядело красивым и активным. Но он солгал.

Когда я попросил своего хорошего коллегу Марка проверить, действительно ли порт в порядке, он запустил Get-NetFirewallPortFilter в PowerShell на машине TFS, и мой порт отсутствовал в списке!

Решение, которое он предложил, заключалось в запуске следующего сценария PowerShell (поскольку брандмауэр играл):

   $port = New-Object -ComObject HNetCfg.FWOpenPort
   $port.Port = 9191
   $port.Name = 'TFS CI Port:9191'
   $port.Enabled = $true

   $fwMgr = New-Object -ComObject HNetCfg.FwMgr
   $profile = $fwMgr.LocalPolicy.CurrentProfile
   $profile.GloballyOpenPorts.Add($port)

Как только это было запущено, входящее правило для порта 9191 появилось в входящих правилах брандмауэра.

Затем я вручную поставил сборку в очередь и впервые увидел, что она завершилась ошибкой (не зависанием!), Причем с файлами журнала! :)

person Victoria    schedule 31.03.2016

arrow_upward
0
arrow_downward

  1. Убедитесь, что учетная запись, под которой запущен агент, находится в роли «Учетная запись службы пула агентов».

  2. Убедитесь, что очередь подготовлена ​​в коллекции (https://your-tfs-server:8080/tfs/your-collection/_admin/_AgentQueue). Если нет - выберите «Новая очередь ..» и выберите существующую очередь.

  3. Убедитесь, что вы развернули агент сборки Windows, точно следуя этой статье.

  4. Попробуйте изменить учетную запись домена, которая является членом группы «Учетные записи служб агента сборки» и принадлежит роли «Учетная запись службы пула агентов», чтобы узнать, будет ли агент работать или нет.

  5. Повторно разверните агент Windows.

person Cece Dong - MSFT    schedule 31.03.2016
comment
Сесе, спасибо, что вернулись. Оказалось, что это правило создания правила для входящего трафика брандмауэра, возможно, для Windows 2012 R2. - person Victoria; 31.03.2016