-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support CloudFormation intrinsic functions in SAM resources #22
Comments
Trying to use Works fine when I manually look up the values and plug in the strings, so figure it must be this same issue. Timeframe on a fix? Any workarounds possible? Loving the new SAM stuff but this is a deal-breaker. |
I am sorry you are running into the bug. Unfortunately there are no workarounds besides switching to regular AWS::Lambda::Function resource. We are actively working on fixing it. Will let you know once its done |
I've been having this issue with Is this bug fix to support all of the intrinsic functions? |
@stuartstevenson #20 was a bug that was fixed. You should be able to use any Fn:: function with Variables property. However you cannot pass the ARN directly to your Swagger. It doesn't work. You should pass function name and construct the ARN there. See this example: https://github.com/awslabs/serverless-application-model/blob/master/examples/2016-10-31/api_swagger_cors/swagger.yaml#L23 |
|
Can you give me an example with the error you received? |
I'll create one tomorrow and post here. |
@sanathkr Thank you for your response. Is there a reason why ARNs in particular cannot be passed as I had made the assumption that the stage variable was just a string i was setting? I would not have assumed that the contents of the string would be validated. |
I was using multiple short form functions in a row which is not supported. So trying
Is improper while
Works. http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-base64.html Notes the problem I had. |
I'm still getting this error when trying to use Resources:
LambdaFunction:
Type: AWS::Serverless::Function
Properties:
Handler: bundle.handler
MemorySize: 128
Runtime: nodejs4.3
Timeout: 3
Events:
List:
Type: Api
Properties:
RestApiId: !ImportValue API-ApiId
Path: /users
Method: GET |
I'm experiencing a variation of this trying to use !Ref as a value in a Function's Environment. Is my only option to switch to AWS::Lambda::Function for now? Edit: I had a typo in my CodeUri attribute and that caused "internal error in transform" which led me here. Sorry. |
!Ref in environment variables is supposed to work out-of-box. Can you post an example? |
It did work. I was mistaken. |
Our org would also like to see Something like this, is what we are thinking (idolized design):
|
Thanks for the comment. Yes, we will support this usecase as well... |
Interestingly, many of the intrinsics work through CodePipeline action for CloudFormation. Is that case handled differently? |
We have just pushed support for Intrinsic functions - https://github.com/awslabs/serverless-application-model/blob/master/HOWTO.md#using-intrinsic-functions It should work everywhere except for the caveats mentioned in the above doc. If you find any scenario where it doesn't work, please create a new bug.
|
Just curious, when is this available? Is it currently available in AWS::Serverless-2016-10-31? |
Should all be available.
…-Joe
Sent via mobile.
On Sep 25, 2017 1:52 PM, "Judah Bernstein" ***@***.***> wrote:
Just curious, when is this available? Is it currently available in
AWS::Serverless-2016-10-31?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-bx4hu56z2sGAJrkkMMihw5r1ot1yoks5sl-hpgaJpZM4K7Jk_>
.
|
I am trying to do something like this to enable both local and CI run but doesn't work: |
Dont know if |
@MaiKaY Thanks. But in may case, I use a S3 location with BucketName and Key for CI. For local with "sam local", my CodeUri value should be "./../../target/helloworld-1.0-SNAPSHOT.jar", which is a string type. |
This is exactly what I'm trying to do as well but I haven't yet been able to find a way around this -- surely this must be a reasonably common use case? I too would like to switch Are there any plans to support the |
@eelixa did you try using the full name for the intrinsic function, versus the shorthand notation? For SAM my understanding is you must use the former. |
@bluepeter Ah right, I didn't realise that was the case. I have the If part working now. Thanks a lot for your help! |
@eelixa would be cool if you can paste your working code here. To avoid similar issues in the future :-) |
I ended up with something like this:
And then:
|
You cannot use the shorthand notation in SAM. Please use, e.g., |
Sorry, removed my prior comment on accident. For anyone confused by @bluepeter's reply to seemingly no-one, I posted about the an API event in an Anyway, I do not see anyone mentioning that shorthand isn't supported except you. The documentation doesn't mention it either, and the pending documentation update (#290) indicates that |
With
Since SAM runs "before" any intrinsic functions are processed, it has no way of getting the path string that you expect to be obtained by resolving the intrinsics. SAM works around this problem in most cases by carefully passing the value (containing intrinsics) directly to the next stage of processing that deploys the stack. In case of Path, we need cannot insert an intrinsic function as a key of a dictionary. Therefore SAM gives up and fails. Policies, on the other hand, are never entirely resolved in SAM. They are passed through directly to the next layer if SAM finds an intrinsic function there. |
Good to know. Thanks for the detailed info. |
in usage plan defintion AWS::ApiGateway::UsagePlan...not able to refer stage name from AWS::Serverless::Api...getting into race situation the usageplan ran ahead of api/stage creation...event i marked dependson:api resource for usageplan resource...but still it is not working |
Hi guys.
Any ideas? |
As noted repeatedly in this thread, you must use the fullly qualified name
of the Sub function, Fn::Sub, not the shorthand !Sub
…On Tue, 24 Apr 2018, 13:16 Bruno Fitas, ***@***.***> wrote:
Hi guys.
I still have problems with Fn::ImportValue and SAM Local.
The following deploys but I'm unable to invoke it locally.
Environment:
Variables:
TOPIC_ARN:
Fn::ImportValue:
!Sub "${AlarmNotificationTopicStackName}-TopicName"
Any ideas?
Thanks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACz40JUgbsOQVpwkQVdLTpOd1Oko_gr5ks5trxe6gaJpZM4K7Jk_>
.
|
Can some please lock this issue?
…On Tue, 24 Apr 2018, 18:34 Pete Wildsmith, ***@***.***> wrote:
As noted repeatedly in this thread, you must use the fullly qualified name
of the Sub function, Fn::Sub, not the shorthand !Sub
On Tue, 24 Apr 2018, 13:16 Bruno Fitas, ***@***.***> wrote:
> Hi guys.
> I still have problems with Fn::ImportValue and SAM Local.
> The following deploys but I'm unable to invoke it locally.
>
> Environment:
> Variables:
> TOPIC_ARN:
> Fn::ImportValue:
> !Sub "${AlarmNotificationTopicStackName}-TopicName"
>
> Any ideas?
> Thanks
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#22 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ACz40JUgbsOQVpwkQVdLTpOd1Oko_gr5ks5trxe6gaJpZM4K7Jk_>
> .
>
|
what's the most recent issue related to this? So that my team can track this issue. |
@OGoodness I've created the #2533 meta-issue to track intrinsic function-related problems |
We quite often use !Ref, !Sub, !Join in properties that are supposed to hold strings such as CodeUri, DefinitionUri, StageName (#19) etc. This is a perfectly valid CloudFormation, but the transformation logic that parses SAM does not resolve intrinsic functions before parsing the property as a string. So the transformation logic would fail and depending on the property it could either return a
validation error
orinternal failure
. Properties that are directly passed down to CloudFormation are unaffected by this problem.This is a feature request to add support for resolving a subset of CloudFormation intrinsics in the transformation logic. We care about only the subset of properties that the transform manipulates, like CodeUri.
Following intrinsics will be supported:
on following properties:
The text was updated successfully, but these errors were encountered: