Azure Pipeline — Builds com erro ao realizar restore de pacotes Nuget na imagem windows-latest (windows-2019 -> windows-2022)

Na segunda feira (21/03/2022) notamos que algumas pipelines de builds que utilizavam a imagem windows-latest simplesmente passaram a “quebrar” no estágio de restore dos pacotes Nuget, com algumas mensagens de erros que não faziam sentido, uma vez que nada foi alterado na pipeline e nem na infraestrutura de nossos projetos.

Irei detalhar neste artigo um pouco do processo de análise que realizamos e como solucionamos o problema. Espero que possa ajudar outros devs que passaram a ter esse problema da noite para o dia.

Como identificar o problema?

Na pipeline de build retornará erro na task de restore dos pacotes Nuget, e ao olhar os logs de execução da task encontrará algumas mensagens de erro “sem sentido” (no nosso caso passou a retornar a mensagem “Package … is not compatible with netcoreapp3.1”), uma vez que nada foi alterado no projeto. Conforme abaixo:

Descobrindo o causador do problema

Diante do problema, começamos a pesquisar e encontramos alguns relatos de problemas em pipelines com a imagem windows-latest e identificamos que a Microsoft havia atualizado a imagem usada pela tag windows-latest para utilizar a imagem windows-2022 e foi então que tudo começou a fazer um pouco de sentido.

Após pesquisarmos um pouco das mudanças que ocorreram da imagem windows-2019 para a imagem windows-2022, um fator bem relevante foi a utilização do .NET SDK 6.0, este que trouxe algumas mudanças do comportamento default utilizado nas versões anteriores.

Sendo assim, a primeira diferença que notamos é que ao executar a pipeline com a imagem windows-2019 (a esquerda), a versão do Nuget utilizada na task de restore foi alterada. Conforme podemos observar abaixo:

A partir disso, resolvemos dar uma consultada na documentação oficial da Microsoft (NuGet tarefa restaurar, empacotar e publicar — Azure Pipelines | Microsoft Docs) e encontramos os seguintes pontos abaixo:

Na documentação da task Nuget restore, a Microsoft informa que a autenticação para feed do Nuget que era realizada implicitamente na tarefa de restore está depreciada e receberá apenas correções de bugs críticos, recomendando assim que seja adicionada uma nova task nas pipelines responsável por realizar a autenticação com os feeds (NuGet autenticar — Azure Pipelines | Microsoft Docs).

Neste ponto da documentação, a Microsoft recomenda que o restore de pacotes, caso esteja usando .NET Core ou .NET Standard, seja realizado pela task de restore usando o comando dotnet restore da CLI do .NET Core. (Tarefa de CLI do .NET Core — Azure Pipelines | Microsoft Docs)

E neste ponto, a Microsoft registra a diferença que encontramos ao rodar a pipeline com a imagem windows-2019. Aqui ela confirma que na nova versão a task de Nuget restore utilizará como default a versão 4.1 do Nuget (comportamento encontrado na imagem windows-2022, porém na imagem windows-2019 era utilizada outra versão).

Resolvendo o problema

De acordo com os comportamentos encontrados, e as recomendações da documentação oficial da Microsoft, realizamos os seguintes ajustes:

• Criamos a task de autenticação Nuget:

Abaixo está a configuração da nossa task antes de qualquer alteração, aqui utilizávamos a task de Nuget restore para autenticar e restaurar os pacotes na mesma task.

De acordo com a diretiva da Microsoft, criamos uma nova task separando a autenticação aos feeds de repositórios do processo de restore em sí.

Para nosso caso, como utilizamos um feed do Nuget (Azure Artifacts) próprio que está hospedado na mesma organização do Azure Devops, não precisamos setar outros parâmetros para a task de autenticação. Por default, quando o feed está na mesma organização que a pipeline a autenticação é realizada sem maiores configurações. Sugiro dar uma consultada na documentação oficial para entenderem os parâmetros de configuração disponíveis ( NuGet autenticar — Azure Pipelines | Microsoft Docs)

• Migrar a task de Nuget restore para utilizar a task dotnet restore

Conforme podemos observar abaixo, antes (a esquerda) utilizamos a task de nuget restore para resolver toda a dependência de pacotes. Porém como a diretiva da Microsoft para os casos de .NET Core e .Net Standard é que seja utilizada a task de dotnet restore (a direita):

Importante ressaltar que alguns parâmetros mudaram de nome, e caso não seja alterado a task retornará com erro. Vale aqui uma consulta a documentação oficial para entender os parâmetros necessários para sua necessidade (Tarefa de CLI do .NET Core — Azure Pipelines | Microsoft Docs)

PS: Um aviso importante é que a tag de configuração do arquivo Nuget.config mudou de nome, antes era vstsFeed e agora é nugetConfigPath (nos atentamos a essa mudança da pior forma, quebrando a cabeça por erro :/)

E basicamente com estas duas mudanças nossa pipeline voltou a funcionar corretamente. Segue abaixo yaml com as mudanças realizadas comparando a versão anterior (a esquerda) com a versão atual (a direita)

Espero que este tutorial ajude a solucionar este mesmo problema para outros devs, sem que precisem fazer toda a análise que realizamos. Além disso, se tiver algum conhecimento a agregar neste artigo, não deixe de comentar!