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
The example code in the Uploading Local Artifacts to an S3 Bucket doc says that the Code property of a AWS::Lambda::Function resource can be a string (pathname) for the purpose of using it with the aws cloudformation package command which then replaces it (in its output) with a proper Code value.
I’m not sure how to incorporate this new type option for Code, or if it’s the right way to approach it, so I’m just bringing it up for discussion here.
NOTE: The docs are a bit outdated and there is a PR to fix them, but I have tested it with aws cloudformation package command and it seems to accept and properly handle the pathname as documented.
NOTE2: For now, I worked around this limitation with a “double type assertion”:
import{Code}from"cloudform-types/types/lambda/function";/* ... */constFunctionCode=newLambda.Function({/* ... more props */Code: ("/Users/vlad/src/repetitor.tsx/src/cloud/aws/lambda/test-lambda/"asany)asCode}
The text was updated successfully, but these errors were encountered:
The example code in the
Uploading Local Artifacts to an S3 Bucket
doc says that theCode
property of aAWS::Lambda::Function
resource can be a string (pathname) for the purpose of using it with theaws cloudformation package
command which then replaces it (in its output) with a properCode
value.I’m not sure how to incorporate this new type option for
Code
, or if it’s the right way to approach it, so I’m just bringing it up for discussion here.NOTE: The docs are a bit outdated and there is a PR to fix them, but I have tested it with
aws cloudformation package
command and it seems to accept and properly handle the pathname as documented.NOTE2: For now, I worked around this limitation with a “double type assertion”:
The text was updated successfully, but these errors were encountered: