https://pulumi.com logo
Join Slack
Powered by
When I add the following line to my inline program...
# automation-api
p
When I add the following line to my inline program it complains with`Program run without the Pulumi engine available` :
Copy code
const opts = { ...options.Azure('azure'), region: stack.region, resourceGroupName }
options.Azure is located in a separate TS package and does the following:
Copy code
export function Azure(
    name: string,
    opts?: CustomResourceOptions,
    providerOptions?: ProviderOptions,
): AzureOptions {
    const subscriptionId = cfg.require('subscriptionId')
    const provider = new azure.Provider(
        name,
        {
            tenantId,
            subscriptionId,
            clientId: cfg.require('clientId'),
            clientSecret: cfg.requireSecret('clientSecret'),
        },
        providerOptions,
    )
    return {
        subscriptionId,
        provider,
        ...opts,
    }
}
I suspect it has something to do with it being in a separate package… any ideas?
l
Where does 
cfg
come from? If you call any Pulumi static method (e.g. getStack()) without having started the engine, you will see this error. Maybe you can change the order of imports? Or change 
cfg
from being created inside the imported module to being passed into it from the main program?
If you have something like 
const cfg = new pulumi.Config();
in your module, that's definitely not going to work. Do that in you main program and pass it to the module.
Even if it did work, you shouldn't do it. Coupling your module to the shape of your program's config file is not a good idea and will bite you in the future. App-specific config should be handled in an app-specific way, and passed into modules in module-specific APIs.
Which is exactly the model used throughout Pulumi, for example in their 
args
and 
opts
constructor parameters.
p
yes, this was correct
I suspected this was the initial issue and fixed
but we were also calling getProject in a similar manner that I missed 🙂
Coupling your module to the shape of your program’s config file is not a good idea and will bite you in the future
We use it to override the default provider behavior and these are just helpers to build out the correct providers.
(and these are only ever called in projects and passed to modules/components)
l
Even if you're doing for good reasons, it will help future you if you define an API for the non-default-provider-overrider function, and pass values into it. Allowing the function to call config.get is too much coupling and it is likely to cause problems in the future.
p
I don’t disagree but I also dont want to have to type it out everytime ¯\_(ツ)_/¯
Open in Slack
PreviousNext
Powered by