You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our CloudFormation templates all have a GitSha parameter that indicates which commit of the application you want to deploy. So when we define Lambda function's now, the code Property is an object that looks like this:
Yes, this is not great, and something we're aware of (but unsure how to fix short of introducing a more complex type system involving generics). Before we start making changes, we want to make an inventory of how often these kinds of scenarios occur in practice.
As a workaround, you can bypass the typechecker by putting as any after the value. It will ultimately synthesize to the correct CloudFormation.
We have CI systems that build lambda code bundles for our applications on commit. These systems write bundles to S3 locations like this:
Our CloudFormation templates all have a
GitSha
parameter that indicates which commit of the application you want to deploy. So when we define Lambda function's now, the code Property is an object that looks like this:I can't seem to reproduce this behavior through the LambdaS3Code construct, which will only accept a
string
for the key argument.The text was updated successfully, but these errors were encountered: