https://pulumi.com
Join Slack
This message was deleted.
# azure
s
This message was deleted.
b
if you run the commands inside an AzureCLI@1 task it will automatically log in for you
there's an inlineScript property you can use, but i've never tried with bash
doing it that way is the only way i've ever had any AZ login things work
w
but I get another regular task to work for some reason. Maybe that doesn't use the az cli on a second thought, I'm only pushing an image to acr in the working step which I think is done without az cli.
Also, when I have set the service principal configuration in the stack config I think that is what should be used to authenticate against azure. So I'm not sure what is going on since it works when I run it locally but not on azure devops.
Is it true that doing it the way @better-rainbow-14549 describe is the only way to get the az to work? I though having the azure credentials for a service principal in the 
pulumi.<stack>.yaml
would do the trick. I could use the tasks created by pulumi, but I would rather run it from another script I have and the tasks is sort of focused on running pulumi directly.
@tall-librarian-49374 have you experience anything like I describe in the issue.
t
I don’t have any immediate bright ideas. I guess the key question is what’s the difference between local and DevOps?
w
yeah, and that is what I tried to figure out by running it in a container locally... but no success. I can probably find ways to work around this, but I'm just curious to what is going on. Do one have to use a 
service connection
for it to work from devops? Eitherway, I would expect another error message than what I get if that was the case.
r
Just a guess: Could it be related to different providers used for azure and e.g. azuread, so that one is falling back to 
az
settings / env vars instead of using the credentials inside the pulumi config? I once had this specific issue when I migrated from the single module for azure to two of them and didn’t take care that I need to specify the az client config twice.
But as far as I know that’s only the case for things related to AD access. All others I’m using are handled by the 
azure:
prefix.
If you are creating an `azuread.ServicePrincipal`or 
azuread.Application
this might be an issue and worked before locally because you had a proper 
az
configuration which is not there in CI/CD.
Not sure how you are integrating with Azure DevOps to inject the env vars (parts of that are commented out at the moment).
I personally prefer to configure my pulumi resource providers explicitly inside the pulumi config or (if more complex in code with values from pulumi config - and explicitly creating providers) - over the env var approach. So the only thing I need in CI is the one env var for pulumi and not several of them for all providers. That also makes it a lot easier to have several stacks for different environments because I don’t need to replicate the same environment specific things also in CI (like e.g. the azure SP password) to be used when the pre-prod stack is deployed.
w
That is what I'm aiming for as well @rhythmic-finland-36256, to have the config in the pulumi config file so I only need one setting in devops. That also makes it easier to test the setup in other places like github actions if I want to (and I do 🙂 ).
I could probably find a workaround, but I would like to know what goes on and I'm now getting help.
r
I’m pretty sure if you logout from your azure cli locally, it won’t work either. Or are you looking for the way to configure the azure provider with env vars like commented out here? https://github.com/mastoj/sweetspot/blob/f786c4cbcbd70b73cd6a9493a3321d35c401e9de/azure-pipelines.yml#L43 Then it might be more of an Azure DevOps config issue than a pulumi one…
Managing all that inside pulumi is both a secure and also a straight-forward way that drastically reduces CI/CD system configuration complexity.
w
I think it works locally since I manage to run it from a docker container without authenticating with 
az login
No, I do not want to use env variables that way ideally (only as a workaround). I prefer to have the config in the 
pulumi.<stack>.yaml
r
OK.
I cannot imagine that this works without an authenticated az cli
where should it know which SP to use?
Or do you mean “when specifying the env vars accordingly for the 
docker run
command”?
w
Now I understand the misunderstanding. You only looked at the core project, yeah that one I've only deployed locally. The repo has three pulumi projects, and the one that should work has the values in 
Pulumi.dev.yaml
(https://github.com/mastoj/sweetspot/blob/minimal_error/src/infrastructure/Sweetspot.Infrastructure.Application/Pulumi.dev.yaml). That branch only has the relevant code to reproduce to make it easier to reproduce.
Short update. My issue seems to be have related to either wrong or inconsistent line endings in the files. I’ve been editing the files straight from win10 as well as wsl, since why not. That plus probably some incorrect autocrlf setting in git seems to be the problem.
😲 1
t
Oh wow
w
Yeah, it is super weird. Another update is that isn’t fixed. The build was a false positive for other reasons. I still believe it has something to do with the file encoding, file endings or something related to that.
4 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by