Ok, so if you've read Part 1, you know that you should protect the aws-exports.js file. The first method I will show is using only AWS Amplify tools.
Why store it when it gets generated every time, right? In part 1, I mentioned that amplify init, amplify pull, and any amplify add <feature> or amplify remove <feature> will cause the aws-exports.js file to be recreated.
I've committed the source tree on several projects with dependencies on src/aws-exports.js, which will more than break the build if it doesn't exist.
So let's say that you're on your laptop. You've successfully amplify init to create your environment or used the AWS Amplify Studio UI to set up your environment and then run amplify pull --appId <snip> --envName dev. You've got your src/aws-exports.js setup, and you're building locally. You commit your code in and move over to your desktop, and pull your code down. But running dev breaks, src/aws-exports.js doesn't exist.
It's pretty straightforward. We're going to run amplify pull --appId <snip> --envName dev again to have it pull down all the backend settings and generate your src/aws-exports.js for you.
A quick note there, if you added a feature on your desktop, let's say new storage (S3) for the application, the next time you commit and switch to your laptop, you'll perform another amplify pull to get back in sync. You can always run amplify status to see if you are up to date against the deployed version.
Now let's talk builds and CI/CD. One of the most fantastic features that you get pretty much out of the box in Amplify is a complete CI/CD pipeline. I'll look at doing a dedicated post for that feature, but I'm going to leave the details out of scope for now. The big thing that I want to point out is how it to can generate the src/aws-exports.js
Each build is executed inside a container in the AWS build environment; it inherits the IAM role provided, which allows it to authenticate to the Amplify framework and pull down the settings. This permission configuration happens by default with the default build settings. In Part 3, I'll show you how to override or specify these settings using Environment Variables.
The key to this, though, is to think of it as doing a amplify pull at the beginning of every build. If you're modifying your aws-exports.js file (you never should), those modifications will not make it in this build. If the backend had changed and you didn't amplify pull before developing, validating, and committing, your backend references may be out of sync.
Top comments (0)