Я нахожусь в процессе миграции ряда умеренно сложных приложений с общими компонентами в надлежащую среду CI / CD, предоставленную TeamCity.В рамках миграции мы хотим, чтобы совместно используемые компоненты были упакованы как пакеты NuGet, а затем, когда они развернуты, полагаются на триггер «добавлен пакет» для запуска сборок в нисходящем направлении.
TeamCity делает это умеренно простым в теории: установите шаг сборки NuGet Pack и поставьте галочку в поле Publish created packages to build artifacts, и пакет должен оказаться в ленте.
К сожалению, покаМне удалось заставить последующие сборки обратиться к нашему каналу, они не могут получить пакеты.Проще говоря, он добавляет дополнительные app в URI для пакета:
http://the.teamcity.server/app/nuget/.../package.nupkg
вместо этого сохраняется как
http://the.teamcity.server/app/app/nuget/.../package.nupkg
, поэтому восстановление пакета завершается неудачно.Однако, как ни странно, я могу использовать пакеты при разработке с использованием фида в Visual Studio, так что это не может быть полностью ошибочным.Кто-нибудь знает, почему я могу получить это неправильное расположение пакета в узле Content документа XML, полученного при доступе к .../FeedService.svc/Packages(Id='PackageName',Version='1.0.0.0'), и узнать, есть ли разумный способ остановить это или альтернативная команда восстановления (например, ближе кчто бы ни делала Visual Studio) вместо шага сборки NuGet Restore, который будет игнорировать это местоположение и искать пакет альтернативным способом?
Обратите внимание, что я , а не администратор длясервер TeamCity, только для проекта моей команды в нем;следовательно, я не могу комментировать (или изменять) конфигурацию URL-адреса канала NuGet.Я могу сказать, что канал не пустой - так что, вероятно, он успешно используется в других местах.