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 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
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.