Hi folks, and maybe especially @clever-sunset-76585. In a couple of our Pulumi programs, we are importing some shared NuGet packages from an internal package feed in our Azure DevOps project. This works fine, for example using the built-in

DotNetCoreCLI@2

task. Anything executing in the pipeline is able to implicitly authenticate to the package feed. Except the Pulumi Task Extension for Azure DevOps. When the program is built by Pulumi, this authentication for some reason does not work. It is as if the normal environment variables, or some other ambient/contextual thing, are not visible to dotnet.exe when it’s called from Pulumi.

Hi Daniel, I'll take a look today, but my guess is that because the Pulumi CLI is running a

dotnet build

of its own, it probably also tries to restore the NuGet deps again, which fails possibly due to the ambient context thing with authenticating to an internal package feed. Until I take a look, though, I am wondering if there is a way to disable Pulumi CLI from rebuilding the solution by passing some flags, @tall-librarian-49374?

I believe there’s no way to disable the build currently…

@clever-sunset-76585 I looked through the Pulumi CLI argument, and could not find anything to that effect.

I believe there’s no way to disable the build currently…

Is that worth adding as a feature? I can see how that might be useful in cases where you are only deploying from pre-built artifacts rather than rebuilding from source again.

If there was a way to pass-through arguments to

dotnet

that would solve the issue too. Then I could pass

--no-restore

and work around this issue that way.

If there was a way to pass-through arguments to

dotnet

that would solve the issue too.

To my knowledge, no. But @tall-librarian-49374 please correct me if I am wrong.

There’s https://github.com/pulumi/pulumi/issues/3509 but I’m not sure where Go got from there

Yeah, I know there’s not - I meant, that would also be a feature addition that would solve my problem

Thank you!