https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
w
I don't recall yet seeing anyone do that - but it should certainly work.
s
Just using the lambda SDK and having an apply on the id output or similar?
w
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.
s
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
w
This was new in the TF provider a month or two ago if I recall correctly.
s
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
This seems like it should work though:
Copy code
if (!inputs.suppressFirstInvoke) {
            certFunction.name.apply(async (functionName) => {
                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)
w
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
.
s
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]) => ....)
to ensure it didn’t actually run until it existed.
A resource 
create
callback would be ideal though.
w
s
That would allow for a provisioner-like workflow too
w
Yep - exactly.
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by