it-swarm.com.ru

Дайте Дженкинсу знать о собственном источнике пакетов NuGet

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

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

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

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

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

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

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

  2. Я также немного поигрался с config-файлами в AppData и ProgramData, добавив источник в теги package-source в файлах и даже сделав его активным, но это тоже не помогло.

  3. конечно, принятие пакетов было бы обходным путем, но это не желаемый результат, так как мы хотели бы игнорировать пакеты в scm.

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

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

16
nozzleman

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

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

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

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

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

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

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

21
frank koch

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

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

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 путем изменения одного и того же файла конфигурации.

9
Fábio Junqueira

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

0
daviesdoesit