Amplify-cli: Creating function and doing amplify push results in cloudformation `Parameters: [S3DeploymentBucket, S3DeploymentRootKey] must have values` error
Describe the bug
I added a lambda function through amplify cli and did amplify push. Also tried amplify function push. The push failed with:
UPDATE_FAILED <redact>AmplifyCLI AWS::CloudFormation::Stack Wed Apr 24 2019 10:21:12 GMT-0600 (Mountain Daylight Time) Parameters: [S3DeploymentBucket, S3DeploymentRootKey] must have values
This error above is with my graphql API stack.
Then what I did is just touch one of my custom nested stacks to force an "Update" on my graphql API. The the push succeeded.
To Reproduce
Steps to reproduce the behavior:
- Have a graphql API with some custom stacks pushed
- Create a lambda function through amplify console. amplify status will show only the function needs to be created and there is no changes elsewhere.
- Do amplify push
- You'll get the error and push fails
- Force the graphql API to go in "Update" state by touching one of the nested stack json
- Do amplify push, it succeeds and the lambda function is created.
Expected behavior
Lambda function creation should succeed without having to update the Appsync/GraphQL API portion of the stack.
Additional context
Running 1.6.4. Also tried reverting to 1.6.3 but got same error.
hisham
All 15 comments
I have the exact same error when I push code to my repository and trigger an automated build in the console. The issue only occurs if I don't make a change to my Graphql. Steps to reproduce include:
- Make a change to my code and schema.graphql file
- Commit and push code
- Automated deployment succeeds
- Go back to code and make a change to application (no changes to graphql)
- Commit and push code
- Automated build fails
- Go back to code, add a new line to my schema.graphql file
- Commit and push
- Automated build succeeds.
onedotover
on 27 Apr 2019
I have this issue too, but cannot figure out how to reliably reproduce it.
et304383
on 1 May 2019
Also hitting this issue with no discernible changes that should affect CFN between deploys on my end.
davekiss
on 2 May 2019
@hisham @et304383 @onedotover @davekiss do you guys have any custom stacks or resolver override? We haven't been able to reproduce this issue
yuth
on 2 May 2019
Yes I do have custom stacks in the api/<my-api>/stacks/ dir.
hisham
on 2 May 2019
@hisham Can you share a bit more details about what your project looks like? I have been unable to reproduce this as well. I have a project with two functions and a GraphQL api with two custom stacks each creating a table and resolver. When you look at your build directory after a push do you see the "S3DeploymentBucket" and "S3DeploymentRootKey" in the parameters.json in the build directory? They shouldn't have changes since the last deployment because nothing changed but you should see them.
I have been able to add functions without changing the api, change functions without changing the api, change a function and the api, add custom stacks, and change the api without changing anything else.
mikeparisstuff
on 2 May 2019
Yes, I added to the CustomResources.json file to include Lambda resolvers I'm using.
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "An auto-generated nested stack.",
"Metadata": {},
"Parameters": {
"AppSyncApiId": {
"Type": "String",
"Description": "The id of the AppSync API associated with this project."
},
"AppSyncApiName": {
"Type": "String",
"Description": "The name of the AppSync API",
"Default": "AppSyncSimpleTransform"
},
"env": {
"Type": "String",
"Description": "The environment name. e.g. Dev, Test, or Production",
"Default": "NONE"
},
"S3DeploymentBucket": {
"Type": "String",
"Description": "The S3 bucket containing all deployment assets for the project."
},
"S3DeploymentRootKey": {
"Type": "String",
"Description": "An S3 key relative to the S3DeploymentBucket that points to the root\nof the deployment directory."
}
},
"Resources": {
"EmptyResource": {
"Type": "Custom::EmptyResource",
"Condition": "AlwaysFalse"
},
"AppLambdaDataSource": {
"Type": "AWS::AppSync::DataSource",
"Properties": {
"ApiId": {
"Ref": "AppSyncApiId"
},
"Name": "AppLambdaFunction",
"Type": "AWS_LAMBDA",
"ServiceRoleArn": {
"Fn::GetAtt": [
"AppLambdaDataSourceRole",
"Arn"
]
},
"LambdaConfig": {
"LambdaFunctionArn": {
"Fn::Sub": [
"arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:AppLambdaFunctionName-${env}",
{
"env": {
"Ref": "env"
}
}
]
}
}
}
},
"AppLambdaDataSourceRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": "AppLambdaDataSourceRole",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
},
"Policies": [
{
"PolicyName": "InvokeLambdaFunction",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:invokeFunction"
],
"Resource": [
{
"Fn::Sub": [
"arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:AppLambdaFunctionName-${env}",
{
"env": {
"Ref": "env"
}
}
]
}
]
}
]
}
}
]
}
},
"RequestAppLambdaResolver": {
"Type": "AWS::AppSync::Resolver",
"Properties": {
"ApiId": {
"Ref": "AppSyncApiId"
},
"DataSourceName": {
"Fn::GetAtt": [
"AppLambdaDataSource",
"Name"
]
},
"FieldName": "requestApp",
"TypeName": "Mutation",
"RequestMappingTemplateS3Location": {
"Fn::Sub": [
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/${ResolverFileName}",
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
},
"ResolverFileName": {
"Fn::Join": [
".",
[
"Mutation",
"requestApp",
"req",
"vtl"
]
]
}
}
]
},
"ResponseMappingTemplateS3Location": {
"Fn::Sub": [
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/${ResolverFileName}",
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
},
"ResolverFileName": {
"Fn::Join": [
".",
[
"Mutation",
"requestApp",
"res",
"vtl"
]
]
}
}
]
}
}
}
},
"Conditions": {
"HasEnvironmentParameter": {
"Fn::Not": [
{
"Fn::Equals": [
{
"Ref": "env"
},
"NONE"
]
}
]
},
"AlwaysFalse": {
"Fn::Equals": [
"true",
"false"
]
}
},
"Outputs": {
"EmptyOutput": {
"Description": "An empty output. You may delete this if you have at least one resource above.",
"Value": ""
}
}
}
@onedotover I was able to add that exact stack and update a function without changing the api category and the deployment succeeded. Are you seeing any other issues? Do you see the missing parameters in the build/parameters.json file? Is this happening locally or only in the CI/CD environment?
mikeparisstuff
on 3 May 2019
Yes, I do see these values locally in build/params.json
It only happens for me in the CI/CD flow. Locally if I make a change to a function, save, and run amplify push it works.
onedotover
on 3 May 2019
See attached PR with the fix.
mikeparisstuff
on 3 May 2019
Thanks!
onedotover
on 3 May 2019
I had the same issue. I've upgraded to amplify 1.6.7 and now get this when running amplify init in CodeBuild (with configLevel set to general).
Edit: Docker image is aws/codebuild/nodejs:10.14.1
- Initializing your environment: test
✔ Initialized provider successfully.
Could not read cloudformation template at path: /codebuild/output/srcxxxxxxxx/src/amplify/backend/api/xxxxxx/build/cloudformation-template.json
✖ An error occurred when pushing the resources to the cloud
✖ There was an error initializing your environment.
init failed
{ Error: ENOENT: no such file or directory, open '/codebuild/output/srcxxxxxx/src/amplify/backend/api/xxxxxx/build/parameters.json'
at Object.openSync (fs.js:436:3)
at Object.writeFileSync (fs.js:1187:35)
at writeUpdatedParametersJson (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/lib/upload-appsync-files.js:85:8)
at uploadAppSyncFiles (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/lib/upload-appsync-files.js:126:5)
at process._tickCallback (internal/process/next_tick.js:68:7)
errno: -2,
syscall: 'open',
code: 'ENOENT',
path:
'/codebuild/output/srcxxxxxxxx/src/amplify/backend/api/xxxxxx/build/parameters.json' }
chris-merapar
on 7 May 2019
I discovered that the above issue only occurs when using amplify init with the --yes option. When the yes option is provided the init starts the push (which does in itself seem weird to me) and generates the above exception. If you run init without the yes option and then run push afterwards, it works ok. Now I have a new issue, that the amplify publish fails due to an unhandled exception related to the AWS SDK not finding an AWS accessKey, which I need to investigate further. This is odd as the init was ok and the configLevel is set to general so I would expect it to use the ECS instance metadata.
chris-merapar
on 7 May 2019
@mikeparisstuff what if I don't have a parameters.json file in the build directory? There's one in amplify/backend/api/[api name]/parameters.json. No entries for S3DeploymentRootKey or S3DeploymentBucket.
Edit: note builds work when I push from the CLI but not in the amplify console.
kldeb
on 8 May 2019
@chris-merapar We have PR for that already and is tied to a different issue (opened by you) and tracked spearately. Closing this specific issue as this is fixed.
@aireater We've notified Amplify Console to update their default CLI version in their build images.
kaustavghosh06
on 10 May 2019
Related issues
MageMasher
·
3Comments
rehos
·
3Comments
zjullion
·
3Comments
mwarger
·
3Comments
nicksmithr
·
3Comments