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.

Pulumi Community

I don't recall yet seeing anyone do that - but it should certainly work.

Just using the lambda SDK and having an apply on the id output or similar?

An/all of:
1. Using JS `aws-sdk`
2. Using `aws.lambda.getLambdaInvocation` (somewhat poorly named)
3. Embedding the Lambda inside something which runs during deployment, such as a nested `aws.cloudformation.Stack` which includes a reference to a Pulumi Lambda as a custom resource.

Makes sense. I didn’t realise `getLambdaInvocation` existed, that’s likely the simplest.

I had it set using a cloudwatch trigger, but that seems to be racier on large stacks than I remember

Name is actually `aws.lambda.getInvocation`: <https://pulumi.io/reference/pkg/nodejs/@pulumi/aws/lambda/#getInvocation>

This was new in the TF provider a month or two ago if I recall correctly.

Ah yes, looks that way. Hit a nasty versioning bug using it from an NPM package which was fixed by depending on the dev version so it must be fairly recent I guess

```
        if (!inputs.suppressFirstInvoke) {
            certFunction.name.apply(async (functionName) =&gt; {
                await aws.lambda.getInvocation({
                    functionName: functionName,
                    input: JSON.stringify({}),
                    qualifier: "$LATEST",
                });
            });
        }
```

Hmm, actually no it doesn’t. It tries to invoke it on the preview for some reason.

And then fails as the function doesn’t exist yet (fair enough I guess)

Yes - you will need to call this inside a `.apply` to ensure it only runs when the inputs are known.  

However, I believe that will still run during previews after the initial update but against the old values.

We have plans to allow hooking explicit lifecycle events with callbacks - which is what you would likely really want here.

I think there is technically an ability to check if you are in preview - in general that shouldn't be necessary - but for now it might be required for this scenario: `pulumi.runtime.isDryRun`.

Yup that seems like what I’m after there. It seemed to be running on the first preview in this case since the inputs are all knowable during preview. I’d likely be better running it with `pulumi.all([certFunction.name, certFunction.id]) =&gt; ....)` to ensure it didn’t actually run until it existed.

A resource `create` callback would be ideal though.

<https://github.com/pulumi/pulumi/issues/1691>

That would allow for a provisioner-like workflow too