docs: Miscellaneous minor updates (#847)

- More `app` -> `<APP_NAME>` placeholder updates
- Fix the casing of some proper nouns
- Clarify you don't set the AWS account name in the application environment
  configuration anymore, but in the network[1]
- Misc. spelling mistakes/typos

[1] https://github.com/navapbc/template-infra/releases/tag/v0.11.0

docs/e2e/e2e-checks.md

@@ -96,7 +96,7 @@ To clean the report folder you can run:
 make e2e-clean-report
 ```
 
->*On CI, the report shows up in the Github Actions artifacts tab
+>*On CI, the report shows up in the GitHub Actions artifacts tab
 
 
 ### PR preview environments

docs/infra/set-up-app-build-repository.md

@@ -14,7 +14,7 @@ Before setting up the application's build repository you'll need to have:
 To create the `tfbackend` file for the build repository using the backend configuration values from your current AWS account, run
 
 ```bash
-make infra-configure-app-build-repository APP_NAME=app
+make infra-configure-app-build-repository APP_NAME=<APP_NAME>
 ```
 
 Pass in the name of the app folder within `infra`.
@@ -24,15 +24,15 @@ Pass in the name of the app folder within `infra`.
 Now run the following commands to create the resources, making sure to verify the plan before confirming the apply.
 
 ```bash
-make infra-update-app-build-repository APP_NAME=app
+make infra-update-app-build-repository APP_NAME=<APP_NAME>
 ```
 
 ## 3. Check that the build repository was created properly
 
 Run the [Build and publish GitHub Actions workflow](/.github/workflows/build-and-publish.yml) to build your application's image and publish it to the container image registry you just created. If you have the GitHub CLI installed, you can do this using the following command.
 
 ```bash
-gh workflow run build-and-publish.yml --field app_name=app --field ref=main
+gh workflow run build-and-publish.yml --field app_name=<APP_NAME> --field ref=main
 ```
 
 ## Set up application environments

docs/infra/set-up-app-env.md

@@ -14,7 +14,7 @@ Before setting up the application's environments you'll need to have:
    1. Make sure you update `has_database` to `true` or `false` (defaults to `true`) depending on whether or not your application has a database to integrate with.
    2. Make sure you update `has_external_non_aws_service` to `true` or `false` depending on whether your application utilizes any non-AWS services. Other applications within the same git repo count as external services, so if your application makes API calls to another application service in the same git repo, set `has_external_non_aws_service` to `true`.
    3. If you're configuring your production environment, make sure to update the `service_cpu`, `service_memory`, and `service_desired_instance_count` settings based on the project's needs. If your application is sensitive to performance, consider doing a load test.
-   4. Make sure your application environment is using the AWS Account you want to use by checking the `account_name` property in the environment configuration and updating it if necessary.
+   4. Make sure your application environment is using the network/AWS Account you want to use by checking the `network_name` property in the environment configuration and what account it maps to in the project configuration. Update the values if necessary.
 4. [Create a nondefault VPC to be used by the application](./set-up-network.md)
 5. (If the application has external non-AWS services) [Set up network access to the public internet](./set-up-public-internet-access.md)
 6. (If the application has a database) [Set up the database for the application](./set-up-database.md)
@@ -26,7 +26,7 @@ Before setting up the application's environments you'll need to have:
 To create the `tfbackend` and `tfvars` files for the new application environment, run
 
 ```bash
-make infra-configure-app-service APP_NAME=app ENVIRONMENT=<ENVIRONMENT>
+make infra-configure-app-service APP_NAME=<APP_NAME> ENVIRONMENT=<ENVIRONMENT>
 ```
 
 `APP_NAME` needs to be the name of the application folder within the `infra` folder.
@@ -44,8 +44,8 @@ There are two ways to do this:
 2. Alternatively, run the following from the root directory. This option can take much longer than the GitHub workflow, depending on your machine's architecture.
 
     ```bash
-    make release-build APP_NAME=app
-    make release-publish APP_NAME=app
+    make release-build APP_NAME=<APP_NAME>
+    make release-publish APP_NAME=<APP_NAME>
     ```
 
 Copy the image tag name that was published. You'll need this in the next step.
@@ -55,10 +55,10 @@ Copy the image tag name that was published. You'll need this in the next step.
 Now run the following commands to create the resources, using the image tag that was published in the previous step. Review the terraform before confirming "yes" to apply the changes.
 
 ```bash
-TF_CLI_ARGS_apply="-var=image_tag=<IMAGE_TAG>" make infra-update-app-service APP_NAME=app ENVIRONMENT=<ENVIRONMENT>
+TF_CLI_ARGS_apply="-var=image_tag=<IMAGE_TAG>" make infra-update-app-service APP_NAME=<APP_NAME> ENVIRONMENT=<ENVIRONMENT>
 ```
 
 ## 4. Configure monitoring alerts
 
-Configure email alerts, external incident management service integration and additional Cloudwatch Alerts.
+Configure email alerts, external incident management service integration and additional CloudWatch Alerts.
 [Configure monitoring module](./set-up-monitoring-alerts.md)

docs/infra/set-up-custom-domains.md

@@ -56,7 +56,7 @@ nslookup -type=NS <HOSTED_ZONE>
 
 Define the `domain_name` for each of the application environments in the `app-config` module. The `domain_name` must be either the same as the `hosted_zone` or a subdomain of the `hosted_zone`. For example, if your hosted zone is `platform-test.navateam.com`, then `platform-test.navateam.com` and `cdn.platform-test.navateam.com` are both valid values for `domain_name`.
 
-## 5. Create A (address) records to route traffice from the custom domain to your application's load balancer
+## 5. Create A (address) records to route traffic from the custom domain to your application's load balancer
 
 Run the following command to create the A record that routes traffic from the custom domain to the application's load balancer.
 

docs/infra/set-up-database.md

@@ -57,15 +57,15 @@ If you're not sure whether you need to do anything here, you can skip this and c
 Now run the following commands to create the resources. Review the terraform before confirming "yes" to apply the changes. This can take over 5 minutes.
 
 ```bash
-make infra-update-app-database APP_NAME=app ENVIRONMENT=<ENVIRONMENT>
+make infra-update-app-database APP_NAME=<APP_NAME> ENVIRONMENT=<ENVIRONMENT>
 ```
 
 ## 3. Create Postgres users
 
 Trigger the role manager Lambda function that was created in the previous step to create the application and `migrator` Postgres users.
 
 ```bash
-make infra-update-app-database-roles APP_NAME=app ENVIRONMENT=<ENVIRONMENT>
+make infra-update-app-database-roles APP_NAME=<APP_NAME> ENVIRONMENT=<ENVIRONMENT>
 ```
 
 The Lambda function's response should describe the resulting PostgreSQL roles and groups that are configured in the database. It should look like a minified version of the following:
@@ -110,7 +110,7 @@ Why is this needed? The reason is that the `migrator` role will be used by the m
 ## 4. Check that database roles have been configured properly
 
 ```bash
-make infra-check-app-database-roles APP_NAME=app ENVIRONMENT=<ENVIRONMENT>
+make infra-check-app-database-roles APP_NAME=<APP_NAME> ENVIRONMENT=<ENVIRONMENT>
 ```
 
 ## Set up application environments

infra/modules/notifications-email-domain/resources/logs.tf

@@ -1,4 +1,4 @@
-# Configures AWS SES to send additional logging to AWS Cloudwatch.
+# Configures AWS SES to send additional logging to AWS CloudWatch.
 # See https://docs.aws.amazon.com/ses/latest/dg/event-destinations-manage.html
 resource "aws_ses_event_destination" "logs" {
   name                   = "${local.dash_domain}-email-identity-logs"

infra/modules/service/access_control.tf

@@ -33,7 +33,7 @@ data "aws_iam_policy_document" "ecs_tasks_assume_role_policy" {
 }
 
 data "aws_iam_policy_document" "task_executor" {
-  # Allow ECS to log to Cloudwatch.
+  # Allow ECS to log to CloudWatch.
   statement {
     actions = [
       "logs:CreateLogStream",

infra/modules/service/application_logs.tf

@@ -2,7 +2,7 @@
 # Logs
 #------
 
-# Cloudwatch log group to for streaming ECS application logs.
+# CloudWatch log group to for streaming ECS application logs.
 resource "aws_cloudwatch_log_group" "service_logs" {
   name = local.log_group_name
 

template-only-docs/set-up-team-workflow.md

@@ -45,7 +45,7 @@ In Settings > Code security and analysis, enable the following features:
   - CodeQL analysis - follow GitHub's flow for configuring CodeQL. The "Default" set up option is typically all that's needed for JS and Python codebases.
 - Secret scanning
 
-## Other Github features
+## Other GitHub features
 
 In Settings > General > Features, enable/disable features that you want for your project. For example, turn off the Wiki if your project won't be using it
 

template-only-docs/template-development-workflow.md

@@ -38,4 +38,4 @@ In most cases, after you merge changes to the infra template, the changes will b
 
 ### 4. Clean up: Close the pull request on the platform test repo
 
-Now that the change has been merged to the template and propogated to the platform test repos, you can close the pull request that you created on the platform test repo as it is no longer needed. It is helpful to link to the pull request on the template repo in a comment.
+Now that the change has been merged to the template and propagated to the platform test repos, you can close the pull request that you created on the platform test repo as it is no longer needed. It is helpful to link to the pull request on the template repo in a comment.