Voici un problème qui a un petit goût de réchauffé. Il y a quelques moi j'expliquais ici même la démarche à suivre quand Azure Pipeline dit qu’il est impossible de charger l'index nuget d’Azure Artefact. Aujourd'hui, je reviens avec un sujet très similaire.

Suite à l'installation du SDK .net 8 sur un serveur de build, je me suis retrouvé avec quelques problèmes de builds. Des pipelines hébergés via Azure DevOps Server indiquent avoir des problèmes pour charger l'index d'un repository Azure Artefact.

L'erreur se produit sur une tâche DotNetCoreCLI se trouvant pourtant derrière une tâche NugetCommand(restore).

Si on regarde le log (que je n'ai malheureusement plus sous la main), on constate que la tâche tente d'accéder à Azure Artefact malgré la présence des packages fraichement téléchargés via nuget. La présence du SDK de .net 8 semble changer le comportement par défaut de la CLI.

Pour résoudre ce problème une bonne fois pour toutes, il suffit donc de dire à DotNetCoreCLI de ne pas restaurer les packages nuget. Pour cela, on peut utiliser sa propriété argument et lui passer l'argument --no-restore.

Voici un exemple complet :

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

Moralité

Les paramètres par défaut, c'est mal. Surtout si vos pipelines reposent dessus.