I'm not sure i fully understand the issue.
If the amplify/backend/backend-config.json file is saved in git, does this file determine what resources are deployed, not the "categories" portion of the team-provider-info.json file?
For the past 10 years, I had the opportunity to work in various types of projects, in a number of industries. In that time I have developed some thoughts about software and the process of creating it.
From my understanding, which is based on Amplify failing to deploy and figuring out how to fix it, part of what happens is based on team-provider-info.json file.
If you add an environment variable to a lambda, the files within the lambda directory will say something that translates to "this lambda is expecting to have an environment variable named X".
But, the value of it is defined in the team-provider-info.json file, under the key that matches each environment. That is how Amplify allows you to set different values for the same variable, per environment.
When you add an environment variable, it does not automatically appear in all environments, only in the one you are currently on.
If you commit that file and try to build a different environment based on your git content, it will fail.
Same goes for any resource that you add or remove.
thanks yonathan, the difference in setups must be that I am currently not using env variables.
I got so frustrated with having to set the env variables per lambda function that I now deploy my SSM independently from amplify and share them with all the lambda functions.
For the past 10 years, I had the opportunity to work in various types of projects, in a number of industries. In that time I have developed some thoughts about software and the process of creating it.
The same happened when we added lambdas. If your backend definition, which is environment agnostic, defines something which is not included in the relevant environment entry in team-provider-info.json, then when you try to deploy it will fail.
I think my setup might be slightly different as I'm not seeing the same issue.
To compare, here are the steps I take to create and deploy a project:
I create dev, test, prod envs (in separate AWS accouts) and check in the team-provider-info file to git.
The CICD (github actions) kicks off when the dev branch is changed and deploys to dev + test
A merge to main kicks off a prod deploy.
The CICD checks out the repo, npm i, amplify init (i use an init.sh file for this, see below), amplify push
If i create a new function in dev and merge to main, it creates the new function OK in the prod env, even though the team-provider file remains the same in git.
For the past 10 years, I had the opportunity to work in various types of projects, in a number of industries. In that time I have developed some thoughts about software and the process of creating it.
Second, I think what you've made is the custom CI/CD process that solves this problem because you also needed to have different environments on different accounts.
Thank you, it took a lot of pain, frustration and searching through github issues to find that resolution.
I agree with your article: amplify sells a great story if you go down the happy path, but stray slightly, and you're left frustrated.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not sure i fully understand the issue.
If the amplify/backend/backend-config.json file is saved in git, does this file determine what resources are deployed, not the "categories" portion of the team-provider-info.json file?
Hi Conor,
From my understanding, which is based on Amplify failing to deploy and figuring out how to fix it, part of what happens is based on
team-provider-info.jsonfile.If you add an environment variable to a lambda, the files within the lambda directory will say something that translates to "this lambda is expecting to have an environment variable named X".
But, the value of it is defined in the
team-provider-info.jsonfile, under the key that matches each environment. That is how Amplify allows you to set different values for the same variable, per environment.When you add an environment variable, it does not automatically appear in all environments, only in the one you are currently on.
If you commit that file and try to build a different environment based on your git content, it will fail.
Same goes for any resource that you add or remove.
thanks yonathan, the difference in setups must be that I am currently not using env variables.
I got so frustrated with having to set the env variables per lambda function that I now deploy my SSM independently from amplify and share them with all the lambda functions.
The same happened when we added lambdas. If your backend definition, which is environment agnostic, defines something which is not included in the relevant environment entry in
team-provider-info.json, then when you try to deploy it will fail.I think my setup might be slightly different as I'm not seeing the same issue.
To compare, here are the steps I take to create and deploy a project:
If i create a new function in dev and merge to main, it creates the new function OK in the prod env, even though the team-provider file remains the same in git.
`#!/bin/bash
set -e
IFS='|'
AWSCLOUDFORMATIONCONFIG="{\
\"configLevel\":\"project\",\
\"useProfile\":false,\
\"profileName\":\"default\",\
\"accessKeyId\":\"${AWS_ACCESS_KEY_ID}\",\
\"secretAccessKey\":\"${AWS_SECRET_ACCESS_KEY}\",\
\"region\":\"us-east-1\"\
}"
AMPLIFY="{\
\"projectName\":\"projname-server\",\
\"envName\":\"${ENV}\",\
\"defaultEditor\":\"code\"\
}"
FRONTEND="{\
\"frontend\":\"ios\"
}"
PROVIDERS="{\
\"awscloudformation\":$AWSCLOUDFORMATIONCONFIG\
}"
CODEGEN="{\
\"generateCode\":true,\
\"codeLanguage\":\"typescript\",\
\"fileNamePattern\":\"graphql/*/.graphql\",\
\"generatedFileName\":\"API.ts\",\
\"generateDocs\":true,\
\"maxDepth\":2\
}"
AUTHCONFIG="{\
\"appleAppId\":\"${AMPLIFY_APPLE_ID}\",\
\"googleAppIdUserPool\":\"${AMPLIFY_GOOGLE_CLIENT_ID}\",\
\"googleClientId\":\"${AMPLIFY_GOOGLE_CLIENT_ID}\",\
\"googleAppSecretUserPool\":\"${AMPLIFY_GOOGLE_CLIENT_SECRET}\"
}"
CATEGORIES="{\
\"auth\":$AUTHCONFIG\
}"
amplify init \
--amplify $AMPLIFY \
--categories $CATEGORIES \
--frontend $FRONTEND \
--providers $PROVIDERS \
--codegen $CODEGEN \
--yes
`
First, nice job!
Second, I think what you've made is the custom CI/CD process that solves this problem because you also needed to have different environments on different accounts.
Thank you, it took a lot of pain, frustration and searching through github issues to find that resolution.
I agree with your article: amplify sells a great story if you go down the happy path, but stray slightly, and you're left frustrated.