J'ai un petit problème concernant la restauration du paquet Jenkins et NuGet.
Ce que j'essaie de faire est de construire des solutions sur Jenkins (qui fonctionne parfaitement). J'ai activé la restauration de package pour la solution, qui génère le dossier .nuget contenant NuGet.exe, NuGet.Config et NuGet.targets.
Sur Jenkins, je rédige certains projets sous forme de paquets NuGet dans une source de paquet privé sur notre serveur. J'utilise ces paquets dans d'autres projets, qui devraient être construits sur Jenkins eux-mêmes.
VS connaît la source du paquet privé, il est configuré dans le fichier global NuGet.Config (celui sous AppData) et il n'est pas désactivé (par défaut).
Maintenant, lorsque j'essaie de construire une solution qui a besoin d'un paquet de la source de paquet privé, la construction échoue, car jenkins l'ignore et consulte donc un paramètre -source
- vide lors de la restauration de paquets qui ne sont pas remplacés en tant que Jenkins ne sait pas sur la source personnalisée.
Ce que j'ai essayé jusqu'à présent
Je sais déjà que l'ajout de la source privée aux solutions NuGet.Config- ou NuGet.Targets-file Package-Source
résoudrait le problème, mais cela voudrait dire que je devrais le faire pour chaque solution que je veux construire à l'aide de Jenkins.
J'ai également joué un peu avec les fichiers de configuration dans AppData et ProgramData en ajoutant le code source aux balises source du paquet et en en faisant même le code source actif, mais cela n'a pas aidé non plus.
bien sûr, engager les paquets serait une solution de contournement, mais ce n’est pas le résultat souhaité, car nous aimerions ignorer les paquets dans scm.
En gros, j'aimerais savoir s'il existe un moyen de rendre Jenkins constamment au courant de la source du paquet privé ou de manipuler les installations de NuGet sur les maschines de développeurs, afin qu'elles génèrent un fichier NuGet.targets
- contenant le paquet privé. la source. Un autre correctif possible serait un paramètre pour msbuild, dont je ne suis pas au courant.
Toute aide est grandement appréciée!
Pour résumer (et prolonger) mes commentaires:
La restauration du paquet Nuget via msbuild est obsolète dans les versions actuelles de Nuget (2.7 et versions supérieures)
Nous utilisons une étape par lots à Jenkins
nuget.exe restore SOLUTIONTOBUILD.sln -source http://nugetserver...
et évitez ainsi que le service Jenkins s'exécute dans un compte différent et recherche le fichier .config à un endroit différent.
Sur les ordinateurs des développeurs, les packages sont restaurés par Nuget-VS-Addin (et non par msbuild). N'oubliez donc pas d'annuler les modifications que l'ancien Nuget-VS-Addin a pu appliquer à vos fichiers de projet.
Plus d'informations peuvent être trouvées dans Nuget-Docs
Une autre solution à ce problème consiste à ajouter votre NuGet.config personnalisé à un répertoire du serveur Jenkins et à ajouter une étape de construction permettant d’exécuter le nuget à l’aide de la configuration personnalisée.
C:\nuget\nuget.exe update "%WORKSPACE%\Project.sln" -ConfigFile C:\nuget\NuGet.config
Un NuGet.config ajoutant une source de paquet personnalisée ressemblerait à ceci:
<?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>
Le fichier autonome nuget.exe peut être téléchargé ici
Cette approche facilite l'ajout de flux personnalisés à tous vos travaux Jenkins en modifiant le même fichier de configuration.
[Windows] Assurez-vous que le compte de service Jenkins est autorisé à voir l'emplacement du package de nuget. Dans mon cas, j'utilisais un compte d'administrateur local qui ne disposait pas des autorisations de domaine nécessaires pour naviguer sur l'emplacement réseau de notre dossier NuGet. Assurez-vous également que les packages ne sont pas imbriqués trop profondément.