Voici une situation des plus cocasses. Des projets utilisent des packages nuget hébergés dans Azure DevOps. Lors de la build, Azure Pipeline indique qu’il est incapable de charger l’index nuget d'Azure Artefacts.

Au premier abord, on peut penser à un problème de droits d’accès. Mais il n’en est rien. Ou du moins le problème est un peu plus tordu que cela. Les pipelines ont bien le droit d’accéder à repository Azure Artefacts.

Le problème se trouve en fait au niveau de la tâche qui cherche à restaurer les packages. Comme beaucoup, j’utilisais DotNetCoreCLI@2. En temps normal, pas de problèmes. La tâche restaure les packages, et compile les projets. Mais, j’avais beau lui indiquer explicitement la configuration nuget, ou l’URL du repository, rien n’y faisait.

Et puis j’ai eu l’idée un peu folle de faire à l’ancienne. Comme pour les vieilles solutions .net Framework. Pour ceux qui n’ont pas connu cette douce époque. La tâche VSBuild@1 doit être précédée d’une tâche NuGetCommand@2 avec l'option restore.

Si on applique le même principe, on s’aperçoit vite que NuGetCommand@2 accède aux packages et à l’index d’Azure Artefacts. La restauration et la build deviennent donc possibles.

Ce qui donne :

steps:
  - task: NuGetToolInstaller@1      
  - task: NuGetCommand@2
    displayName: 'NuGet restore'
    inputs:
      restoreSolution: $(solution)
      command: restore
      feedsToUse: config
      nugetConfigPath: '$(system.defaultworkingdirectory)/Sources/nuget.config'
          
  - task: DotNetCoreCLI@2
    displayName: 'Compilation'
    inputs:
      command: build
      projects: $(solution)
      arguments: '--configuration $(buildConfiguration)'

Note : La tâche NuGetCommand@2 suffit à avoir une solution fonctionnelle. Cependant, j’ajoute une tâche NuGetToolInstaller@1 afin d’éviter d’autres problèmes. Ceux-ci feront l’objet d’un second article.