aws-sam-cli: sam build fails when providing a function LayerArn with a reference to a SSM::Parameter CF param
Description
When running sam build
on a template that includes a Serverless::Function
resource that specifies a LayerArn
property with a reference to a CF Parameter
name that is of Type AWS::SSM::Parameter<string>
with a default value of the name of the param in param store, sam build
reports an invalid Arn.
Steps to reproduce
git clone https://github.com/ericallam/sam-build-ssm-parameter-layer-arn-issue.git
cd sam-build-ssm-parameter-layer-arn-issue
sam build --debug
Observed result
View debug output here
Expected result
sam build
should resolve the actual value of the param in param store and use that to determine if the LayerArn is valid.
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
- OS: macOS Mojave
sam --version
: 0.13.0
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 14
- Comments: 35 (9 by maintainers)
I get that using
--parameter-overrides
works, but it’s a really non-intuitive way to need to getsam build
to work when we want to pass anyAWS::SSM
parameter types.This is exactly how it should behave if the
Ref
is anAWS::SSM::*
parameter. I would imagine a reasonable person wouldn’t expect the parameter value be resolved at build time. Or at the very least, ifsam build
detects this type of parameter, it should output some kind of warning about needing to use a--parameter-override
to pass the validation.Otherwise, one has to search Github issues to find this solution.
For clarity for anyone else fighting this bug the following literally got me working:
sam build --parameter-overrides param1=arn:::::::1 param2=arn:::::::1
@mindrunner
We are doing our best to keep all issues updated. We also made a release on Friday: https://github.com/awslabs/aws-sam-cli/releases So the project is far from dead.
@christophsteiner Assuming the SSM Value is a Parameter in the CloudFormation Template, you can add
--parameter-overrides ParameterKey=MyParam1,ParameterValue=MyValue1
or--parameter-overrides MyParam1=MyValue1
. For build, it just has to be a valid layer ARN. It does not have to exist, since we do not do anything with it but validate it is an ARN.I am trying to work around this to get our CI/CD running again. However, passing
--parameter-overrides
tosam build
does not help at all.Error: <string> is an Invalid Layer Arn.
is what I always get. No matter what parameters I pass for overriding.My deployment script is bloated by workarounds for sam and cloudformation. Is this supposed to be production ready? I cannot believe, I need to maintain two different versions of
--parameter-overrides
forsam
andaws-cli
.Is there any option to not use
sam
? Can I use other tools for building?This issue is more impacting after nested stack feature was released in 1.20.0, see #2763
@dougmolineux
Actually this does work in version 1.18 for me
If you add a default numeric value for MyVersionNumberParameter in your template.
Just my two cents. This is extremely impactful to major deployments which share a common library, and which won’t all be deployed with substacks. This should be a must have for enterprise organizations which want to have organizational reference layers.
I am another wishing for a fix/change for this as well…
sam --version
: 0.17.0Using SSM parameters for SAM template parameters is VERY nice. Not validating the
Ref
would be very OK in thesam build
step since I ASSUME the build is there to pack up your code nicely into a package to be upload-able to S3.Since you are not bundling up the Layers themselves in the code in the SAM Build Step, it makes sense to at least ignore the
Layers
property ofAWS::Serverless::Function
.Properties
.So, I hope to hear that this is something to be fixed in a new-er version in the near future. I prefer to keep my
sam build
steps pretty clean and in line with all of the ‘default’ parameter settings.