I'm wondering.. I've defined my "traditional" pulu...
# automation-api
I'm wondering.. I've defined my "traditional" pulumi project as such:
Copy code
import * as pulumi from "@pulumi/pulumi";
import * as azure from "@pulumi/azure-native";

export const createFunction = async () => { // edit: exported createFunction in addition to stackInfo based on discussion in thread :)
/** edit: Adding more fluff to show how I actually return something from the created variable **/
        const rg = new azure.resources.ResourceGroup("myResourceGroup", {
            location: "location",
            resourceGroupName: "myResourceGroup",
            protect: false // prevents this resource from being deleted. unprotect with `pulumi state unprotect <resource URN>`
        let created : any = {
            parameters: {
                name:  rg.name.apply(name => name),
                location: rg.location.apply(location => location), 
                id: rg.id.apply(id => id),
                resource: rg
    return created   
export const stackInfo = createFunction();
would I be able to import createFunction as my pulumiProgram in automation?
I believe the method signatures that automation API accepts are: sync or async functions that return either void (if there are no outputs) or an output dictionary. Or you could just pass in your existing
You'll actually need to export create function somewhere, but it can certainly be used as long as it fits the type signature: https://github.com/pulumi/pulumi/blob/8e8129012e5c1f2883de86478620e9e32474e660/sdk/nodejs/x/automation/workspace.ts#L237
There would be two ways to do this: 1. top level async function export, you could import this from automation and it works by default with the CLI: https://www.pulumi.com/docs/intro/languages/javascript/#entrypoint 2. have the function in a shared module that both the automation script and CLI program can import from
🙌 1
nice! 🙂
well, i'm going to give it a whirl once I'm absolutely certain that doing a preview will a) not screw with my existing stacks or Pulumi.yaml and b) tbd 😉
sometimes.. there's just so much fear.. 😄
sorry to push again - but thinking about the Project settings here... The way I'm setting it up is that I have my traditional setup with:
Copy code
where Pulumi.yaml has this:
Copy code
name: baseline-infra
runtime: nodejs
description: Baseline infrastructure
config: stacks
  url: <azblob://pulumi-state>
so the question is - if i put the automation script in
- can my LocalWorkspace have an empty projectSettings and it will pick up and use Pulumi.yaml correctly (i.e. find my stacks in the stacks folder)?
For your example you would specify
workDir: folder
and the project settings file should be picked up
this.. is a bit weird.. wondering if something changed.. https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/x/automation/#LocalWorkspace-createOrSelectStack indicates that I first set LocalProgramArgs, then LocalWorkspaceOptions if necessary. LocalProgramArgs have two properties..
neeevermind. So I set up inlineProgramArgs as usual with the projectName, stackName and program (the imported one), then in the LocalWorkspaceOptions I skip projectSettings (because it should be picked up - right?) but set secretsProvider and workdir.
I'm either getting tripped up by typescript OR there's an issue since i'm trying to import a function that uses config.requireObject('xx'), which in turn requires the loading of the stack's Pulumi.stack.yaml first.
Copy code
λ ts-node automation.ts --skip-project

            throw new ConfigMissingError(this.fullKey(key));
Error: Missing required configuration variable 'azure:myvar'
automation.ts is the automation version which has an
import * as current from "./index"
and used like:
Copy code
const stack = await pulumiAutomation.LocalWorkspace.createOrSelectStack({
        projectName: "baseline-infra",
        program: current.createFunction,
        stackName: `${envState}.infra.${stackSuffix}`
        workDir: "."
would it be better to import the function directly into
seemingly not 😞
right - was a relatively trivial fix, bring the offending requireObject() into the exported function, and voila. Anyway - now it's secretsProvider issues - but don't think you all need to get pinged with the play-by-play, so I'll start a new thread if I genuinely get properly stuck 😄