-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Enable Overriding of AWS::AccountId psuedo-parameter for local lambda invocation #2325
Comments
another option could be to add an additional regex pattern in the |
@moelasmar not sure of the process here. Would a PR for this be potentially approved? |
Almost 1 year later. Has this been solved or is there other workaround? @moelasmar hoping for a response. Thanks! |
We too would like to see this solved as it's bloating our CloudFormation templates just so we can reference lambda layers. Our workaround is effectively: Parameters:
AWSLayerAccountId:
Type: String
Default: !Ref AWS::AccountId Then in the functions: Layers:
- !Sub 'arn:aws:lambda:${AWS::Region}:${AWSLayerAccountId}:layer:pg:1' Then: sam local invoke [...] --parameter-overrides AWSLayerAccountId=1234567890 |
We hit this issue also. For what it's worth, I pushed this issue with our enterprise support contact. |
Also an issue for me. Having to add duplicate parameters / avoid Pseudo params to be able to make full use of local testing capabilities |
Describe your idea/feature/enhancement
I'd like to be able to override the
AWS::AccountId
pseudo parameter insam local
commands , similar to how the--region
option overrides theAWS::Region
pseudo-parameter.This most common use-case where this would be needed is if you have parameterized ARNs in the
Layers
node of the template (issue #1736). However, I have a use-case where even in local development, I may want to do end-to-end testing which interacts with SNS topics, whose ARN's also have theAWS::AccountId
pseudo-parameter in my template.At this point, if you depend on this parameter to access deployed resources from the local context, you receive a
403
, because you don't have access to resources from account123456789012
Proposal
--account-id abcde12345
option insam local
commands, possibly like the theaws_creds_options
(doing it this way would mean adding anaccount_id
prop to the Context obj-- not sure if it'd just be preferable to have it be a standalone value accessible throughaccount_id
in thecli
method, so as not to modify the existing Context object), and then constructingInvokeContext
with an additional kwargaws_account_id=ctx.account_id
2.) Update the
InvokeContext
class, to handle _aws_account_id:IntrinsicSymbolTable.handle_pseudo_account_id
from:
to (matching the impl of
handle_psuedo_region)
:Things to consider:
No
Additional Details
I've tested it out locally and it does work as expected. I'm willing and ready to put together a PR, if this seems like a good plan.
The text was updated successfully, but these errors were encountered: