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

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.

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.

There is https://github.com/mastoj/sweetspot/blob/f786c4cbcbd70b73cd6a9493a3321d35c401e9de/src/infrastructure/Sweetspot.Infrastructure.Core/Program.fs#L42 … but nothing defined in … https://github.com/mastoj/sweetspot/blob/f786c4cbcbd70b73cd6a9493a3321d35c401e9de/src/infrastructure/Sweetspot.Infrastructure.Core/Pulumi.dev.yaml

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.

I could probably find a workaround, but I would like to know what goes on and I'm now getting help.

Managing all that inside pulumi is both a secure and also a straight-forward way that drastically reduces CI/CD system configuration complexity.

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

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”?

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.