Сделайте Jenkins осведомленным о стандартном источнике пакета NuGet

У меня есть небольшая проблема в отношении восстановления Jenkins и NuGet.

То, что я пытаюсь сделать, это построить решения для jenkins (который отлично работает). Я включил восстановление пакета для решения, которое генерирует .nuget-папку, содержащую NuGet.exe, NuGet.Config и NuGet.targets.

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

VS знает об источнике частного пакета, он настроен в глобальном файле NuGet.Config(тот, который находится в AppData), и он не отключен (по умолчанию).

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

Что я пробовал до сих пор

  • Я уже знаю, что добавление частного источника в решения NuGet.Config- или NuGet.Targets-file Package-Source решит проблему, но это будет означать, что я должен был бы сделать это для каждого решения я хотите построить с помощью Jenkins.

  • Я также немного поработал с конфигурационными файлами в AppData и ProgramData, добавив исходный код в теги источника пакета в файлах и даже сделав его активным источником, но это не так помогите

  • of cource, отправка пакетов будет обходным путем, но это не желаемый результат, поскольку мы хотели бы игнорировать пакеты в scm.

В принципе, я хотел бы знать, есть ли способ заставить Jenkins постоянно знать об источнике частного пакета или манипулировать установками NuGet на машинах разработчиков, чтобы они генерировали NuGet.targets файл, который содержит частный пакет-источник. Другое возможное исправление будет параметром для msbuild, о котором я не знаю.

Любая помощь очень ценится!

Ответы

Ответ 1

Подводя итоги (и расширяя) мои комментарии:

Восстановление пакета Nuget с помощью msbuild устарело в текущих версиях Nuget (2.7 и выше)

Мы используем пакетный шаг в Jenkins

nuget.exe restore SOLUTIONTOBUILD.sln -source http://nugetserver...

и избегайте тем самым проблемы, с которой служба Jenkins работает в другой учетной записи и ищет .config в другом месте.

На машинах разработчика пакеты восстанавливаются с помощью Nuget-VS-Addin (а ​​не с помощью msbuild), поэтому не забывайте отменять изменения, которые старый Nuget-VS-Addin мог применить к вашему проекту, файлы.

Дополнительную информацию можно найти в Nuget-Docs

Ответ 2

Другим решением этой проблемы является добавление пользовательского NuGet.config и исполняемого файла в каталог на сервере Jenkins и добавление шага сборки для запуска nuget с использованием настраиваемой конфигурации.

C:\nuget\nuget.exe update "%WORKSPACE%\Project.sln" -ConfigFile C:\nuget\NuGet.config

A NuGet.config добавление настраиваемого источника пакета будет выглядеть примерно так:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
    <add key="My Custom Package Source" value="http://localhost/guestAuth/app/nuget/v1/FeedService.svc/" />
  </packageSources>
  <activePackageSource>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </activePackageSource>
</configuration>

Автономный nuget.exe можно скачать здесь

Этот подход упрощает добавление настраиваемых каналов во все ваши задания jenkins путем изменения одного и того же конфигурационного файла.

Ответ 3

[Windows] Убедитесь, что учетная запись службы Jenkins имеет разрешение на просмотр местоположения пакета nuget. В моем случае я использовал локальную учетную запись администратора, у которой не было домена perms, необходимого для навигации по сетевой папке нашей папки NuGet. Кроме того, убедитесь, что пакеты не слишком глубоко вложены.