Comment obtenir TFS2015 Build (Build.vnext) et la restauration du package NuGet pour utiliser les sources de package personnalisées

Question

J'essaie d'obtenir notre version TFS2015 ( TFSBuild vnext ) avec VS Team Services. 

Jusqu'ici, la plupart des blogs et de la documentation ont été utiles, sauf lorsque vous essayez de créer un projet utilisant des sources de paquetages personnalisés pour la restauration automatique de paquets NuGet.

J'ai déployé avec succès un agent de génération Team Services (le nouveau mécanisme de génération) et tout semblait bien se dérouler jusqu'à l'échec de la tâche de génération de la restauration des packages NuGet.

L'échec était dû au fait que la source de package personnalisé/privé n'avait pas été sélectionnée dans la configuration du système virtuel installé. Par conséquent, ces packages étaient introuvables. Les paquets traditionnels du flux de paquets NuGet par défaut ont été restaurés sans problème.

Comment spécifier les sources de packages supplémentaires que NuGet doit utiliser lors de l'utilisation d'un agent?

EDIT: vcastro a posé des questions sur l’étape de construction du programme d’installation NuGet et sur la définition des chemins dans la configuration de cette étape de construction. Ce qui précède utilise l'étape de compilation Visual Studio et l'option intégrée permettant de restaurer les packages NuGet. Référez cette image pour référence: 

Answer 1

J'ai raté le Web avec peu de succès, mais après avoir bricolé, les éléments suivants vous aideront:

OK Il semble que les sources de paquet configurées pour NuGet.config soient stockées par compte d'utilisateur, par exemple. 

c:\Users\<<username>>\AppData\Roaming\NuGet\NuGet.config

Mon problème était plus difficile à résoudre car l'agent de génération s'exécutait en tant que Windows Service sous le compte Local System. Donc, pour obtenir la configuration de NuGet pour la construction, je devais utiliser le chemin suivant:

• C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config sous Windows 64 bits
• C:\Windows\System32\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config Windows 32 bits

Vous devrez peut-être disposer d'autorisations élevées pour créer le sous-dossier NuGet et le fichier NuGet.Config .

Remarque: je n'ai pas de solution pour utiliser le compte Local Service. Ce qui précède ne fonctionne que pour le compte Local System (ou un utilisateur réel).

Answer 2

Sinon, vous pouvez également ajouter une étape de compilation NuGet Installer avant l'étape Visual Studio Build dans votre configuration de construction pour restaurer tous les packages NuGet.

Là, vous pouvez passer l'emplacement de votre dépôt privé en tant qu'argument à nuget.exe:

-source "https://www.nuget.org/api/v2/;http://mynugetserver"

Answer 3

Il existe une nouvelle tâche VSTS appelée "NuGet Installer" qui vous permet d’archiver votre fichier NuGet.config et de spécifier les différentes sources de paquets. Exécutez cette tâche avant d’exécuter MSBuild.

Si vous utilisez le flux VSTS NuGet, vous devez ajouter le compte de service de génération au flux pour permettre le téléchargement de packages https://www.visualstudio.com/get-started/package/use/common-identities

 

Answer 4

Ajoutez un NuGet.config à votre projet qui spécifie un autre emplacement de package. Les règles de résolution sont bien définies et expliquées dans le document officiel documentation .

Answer 5

Une solution (qui fonctionne pour moi) est de changer de compte pour le service d'agent de génération tfs 2015 (sur mon ordinateur de build, agent VSO tsf.Agent-PC) en tfsagent, par exemple, et d'ajouter Nuget.config au dossier C:\Users\tfsagent\AppData.\Roaming\Nuget. C'est tout!

Answer 6

1. Spécifiez l’URL de votre flux NuGet personnalisé dans le fichier nuget.config de la solution. Ne stockez aucun nom d'utilisateur ni mot de passe dans ce fichier.

   <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
   <add key="MyCompany" value="https://nuget.mycompany.com:443/nuget" />
   

2. Créez des variables de nom d'utilisateur et de mot de passe dans votre définition de construction dans VSTS. Les variables peuvent être chiffrées et ne seront affichées dans aucune des sorties du journal de construction. Ici, je vais créer les variables MyCompanyNugetUser et MyCompanyNugetPwd.

3. Dans nos étapes de construction, nous ajoutons un script Powershell en première action. Cela lira les variables nom d'utilisateur et mot de passe et mettra à jour le fichier nuget.config de niveau utilisateur sur la machine de construction. Voici l'extrait de code de mon script Powershell intégré:

   Arguments:

   $(MyCompanyNugetUser) $(MyCompanyNugetPwd)
   

   Scénario:

   param($user, $pwd)
   
   $nugetFile = "$ENV:AGENT_HOMEDIRECTORY\agent\worker\tools\nuget.exe"
   Write-Output "Looking for nuget.exe in $nugetFile"
   
   if (-not (Test-Path $nugetFile))
   {
     Write-Error "nuget.exe could not be located."
     return
   }
   
   Write-Output "nuget.exe located"
   
   $cmd = "$nugetFile sources add -name MyCompany -source https://nuget.mycompany.com:443/nuget -username $user -password $pwd -StorePasswordInClearText"
   Write-Output $cmd
   iex $cmd
   

4. Ensuite, nous continuons simplement à exécuter l’étape par défaut de restauration de NuGet à partir des modèles de Microsoft.

Plus ici: https://codingcase.com/2016/07/27/vsts-build-setup-custom-nuget-feeds-with-authentication/

HTH

Answer 7

Dans le RTM de Team Foundation Server 2015, vous devez ajouter une étape de génération du type "Programme d'installation de NuGet" et restaurer les packages du fichier de solution avant d'exécuter le processus de génération actuel. Dans cette tâche, vous pouvez passer l'argument -ConfigFile path/to/nuget.config qui contient votre chemin d'accès au référentiel.

Par exemple:

<configuration>
  <packageSources>
    <add key="Internal Nuget" value="\\srv-nuget\Repo" />
  </packageSources>
</configuration>