https://pulumi.com logo
Join Slack
Powered by
Any ideas, why I can’t use this inside automation-...
# automation-api
i
Any ideas, why I can’t use this inside automation-api process?
Copy code
const config = await authorization.getClientConfig();
const token = await authorization.getClientToken();
Getting:
Copy code
creating error: Program run without the Pulumi engine available; re-run using the `pulumi` CLI
b
Your error looks unrelated. Do you have the Pulumi CLI installed? Automation API currently depends on the CLI still.
i
yep, it’s installed… btw, I have tested this inside automation api in another script and it does work
probably something wrong with my CustomProvider
b
Will probably need more information in order to help then
l
Are you trying to call this code from within your pulumiFunction, or just in the general automation script?
i
I’ve decided to test it inside general automation script (automation api) and it does work @lemon-agent-27707
but it was not working when I’ve embedded it inside CustomResource
but here, you are using
Copy code
let clientID = azure.config.clientId;
let clientSecret = azure.config.clientSecret;
let tenantID = azure.config.tenantId;
let subscriptionID = azure.config.subscriptionId;
instead of
Copy code
const config = await authorization.getClientConfig();
const token = await authorization.getClientToken();
does it make sense? @bored-oyster-3147 @lemon-agent-27707
b
AFAIK you don't want to 
await
inside a pulumi program. Automation API can do this but you'll see weird behavior doing that using the CLI with a local program I think. What is 
authorization
in this context?
i
yep, I know… I am doing await inside Automation API
btw, in the example below you have await inside regular pulumi program 😉
b
Actually there is an important distinction to be made. In the examples you linked, you are correct that the functions 
getAuthorizationManagementClient
and 
getRoleIdByName
each contain a couple `await`s. But it's important to note that when the pulumi program executes them, it does so by piping the resulting 
Promise
to a 
pulumi.output(...)
call here. So the pulumi program is dealing with asynchronous actions only through 
Output<T>
and is not awaiting the 
Promise
explicitly.
Also note that in this line it is passing the 
Promise<T>
to a 
Pulumi.Resource
directly because 
Promise<T>
can be implicitly cast to 
Input<T>
, again, not being awaited explicitly
But to clarify though, your `await`s are located inside your dynamic provider implementation and not in your pulumi program? Because that should be OK
i
yeah, it’s located inside dynamicprovider, but currently I’ve decided to not go with that approach. Anyway, thanks for great explanation @bored-oyster-3147
👍 1
I appreciate that
Open in Slack
PreviousNext
Powered by