https://pulumi.com logo
#azure
Title
# azure
p

powerful-football-81694

03/20/2020, 10:10 PM
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.
Here’s the relevant part of the log.
To add some more information: This is a project-scoped internal package feed in the same Azure DevOps project. The built-in
DotNetCoreCLI@2
task, executing the command
dotnet build
also does now seem to be able to restore packages from this feed. We need to use the
NuGetToolInstaller@1
and
NuGetCommand@2
(restore command) tasks to restore, before doing
dotnet build
.
But even if we do a successful restore using these tasks before running the
Pulumi@1
task, the same error occurs during the latter.
@tall-librarian-49374 @clever-sunset-76585 We’re still struggling with this. Any chance you could help us out?
c

clever-sunset-76585

03/23/2020, 4:09 PM
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?
@powerful-football-81694 also could you please do me a favor and open an issue in the GitHub repo for the Pulumi Task? Here's the link, https://github.com/pulumi/pulumi-az-pipelines-task/issues
t

tall-librarian-49374

03/23/2020, 4:11 PM
I believe there’s no way to disable the build currently…
p

powerful-football-81694

03/23/2020, 4:11 PM
@clever-sunset-76585 I looked through the Pulumi CLI argument, and could not find anything to that effect.
Yes, I can open an issue.
c

clever-sunset-76585

03/23/2020, 4:13 PM
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.
p

powerful-football-81694

03/23/2020, 4:14 PM
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.
c

clever-sunset-76585

03/23/2020, 4:17 PM
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.
t

tall-librarian-49374

03/23/2020, 4:17 PM
There’s https://github.com/pulumi/pulumi/issues/3509 but I’m not sure where Go got from there
p

powerful-football-81694

03/23/2020, 4:18 PM
Yeah, I know there’s not - I meant, that would also be a feature addition that would solve my problem
c

clever-sunset-76585

03/23/2020, 5:51 PM
Thank you!
3 Views