Nuget Provider Error Causes Cake to PseudoFail

[mandalorianbob]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have searched issues to ensure it has not already been reported

Cake runner

Cake Frosting

Cake version

2.0.0

Operating system

Windows

Operating system architecture

64-Bit

CI Server

Azure DevOps

What are you seeing?

When the Nuget Manager sends a message to Standard Error about how it can't connect to a provider, this shows up at the very beginning of the Cake Run, before anything else

##[error][NuGet Manager] [Error] Problem starting the plugin 'C:\Users\VssAdministrator.nuget\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll'. Plugin 'CredentialProvider.Microsoft' failed within 5.101 seconds with exit code -1.

The Cake task then ran to completion, but DevOps marked the task as a failure.

What is expected?

I would expect that if something is going to cause the DevOps Task to fail, Cake would exit immediately.

My problem comes down to the fact that Cake did two things together which it should not do, in my opinion:

1. It let the error propagate to Azure DevOps in such a way that AzDO believed the Task failed.
2. It continued the Task.

The problem with doing these two things together is that things happen in the Cake task that, in my flow, need to be followed by things outside of the Cake task. (Publishing symbols, specifically. I'm working on getting this into Cake, but it's not there yet.)

The things happening outside the Cake task shouldn't happen if the Cake task fails. So my dilemma is that I need Cake to either

• fail immediately if it's not going to return success to AzDO or
• return success to AzDO regardless of what error messages it gets, if it ran to successful completion.

Possibly whatever process Cake is using for Nuget Manager needs to have its error output redirected so AzDO doesn't freak out?

Steps to Reproduce

Unfortunately, I am not sure how to reproduce this. The error itself (the NuGet Provider failing) isn't easily reproducible and is definitely not the fault of Cake.

Output log

No response

[gep13]

@mandalorianbob thanks for reaching out!

I am not sure if I follow exactly what is going on here. Are you able to provide some more information about the exact steps to illustrate what is going on.

Without this information, I am not sure how we can proceed with resolving your issue.

[mandalorianbob]

The tl;dr is - Cake calls NuGet, but there is a failure. Cake doesn't see the failure, but Azure DevOps does. Cake needs to watch for this failure, so that it can fail properly.

More description follows.

So, to be very clear - the error itself isn't the fault of Cake. The actual problem - I've since found out - is that the NuGet Artifacts Cred Provider ( https://github.com/Microsoft/artifacts-credprovider ) has a very low timeout of 5 seconds. So when Cake tries to use NuGet to get the packages for the Build, it fails, with the error shown above.

This failure happens prior to everything else because I believe it's happening when I call

new CakeHost().InstallTool(NuGetUri)
.UseContext<Type>()
.Run(args)

which is of course literally the first thing that happens in a Cake project when I call

dotnet run --project BuildCake.csproj 

I believe dotnet.exe succeeds because my BuildCake.csproj has packages that are required for it to run, so there's no way to run the project without downloading NuGet packages. Which means dotnet.exe must be succeeding in downloading the NuGet packages.

That leaves Cake..

Okay, so to recap, Cake calls NuGet, NuGet Auth fails, and then Cake continues on as if nothing's happened. But that failure gets passed on to Azure DevOps, because AzDo sees output on Standard Error, and so is going to fail the Task when it ends.

I believe that the first package installation is failing, and the others may be succeeding, but that package is the AzureDevOps package, so it takes awhile before Cake actually has a problem with that package missing.

I went poking around the NuGet code, but I can't even figure out how or when nuget.exe is actually called when I call InstallTool. But my belief is that there must be something slipping past because it's happening in nuget cred provider, instead of in nuget itself?

Does that makes sense?