Fixing with prettier

aws-samples · Mar 22, 2024 · cb195db · cb195db
1 parent 2f9ee2d
commit cb195db
Show file tree

Hide file tree

Showing 421 changed files with 3,740 additions and 3,311 deletions.
diff --git a/.prettierignore b/.prettierignore
@@ -1,4 +1,7 @@
-.git
+.git/
 .vscode
 .docusaurus
 test-output
+dist
+lab-timing-data.json
+_application.yaml
diff --git a/cluster/eksctl/cluster.yaml b/cluster/eksctl/cluster.yaml
@@ -7,7 +7,7 @@ availabilityZones:
 metadata:
   name: ${EKS_CLUSTER_NAME}
   region: ${AWS_REGION}
-  version: '1.29'
+  version: "1.29"
   tags:
     karpenter.sh/discovery: ${EKS_CLUSTER_NAME}
     created-by: eks-workshop-v2
@@ -22,7 +22,7 @@ vpc:
 addons:
   - name: vpc-cni
     version: 1.14.1
-    configurationValues: "{\"env\":{\"ENABLE_PREFIX_DELEGATION\":\"true\", \"ENABLE_POD_ENI\":\"true\", \"POD_SECURITY_GROUP_ENFORCING_MODE\":\"standard\"},\"enableNetworkPolicy\": \"true\"}"
+    configurationValues: '{"env":{"ENABLE_PREFIX_DELEGATION":"true", "ENABLE_POD_ENI":"true", "POD_SECURITY_GROUP_ENFORCING_MODE":"standard"},"enableNetworkPolicy": "true"}'
     resolveConflicts: overwrite
 managedNodeGroups:
   - name: default
@@ -35,4 +35,4 @@ managedNodeGroups:
     updateConfig:
       maxUnavailablePercentage: 50
     labels:
-      workshop-default: 'yes'
+      workshop-default: "yes"
diff --git a/docs/authoring_content.md b/docs/authoring_content.md
@@ -5,6 +5,7 @@ This guide outlines how to author content for the workshop, whether adding new c
 ## Pre-requisites
 
 The following pre-requisites are necessary to work on the content:
+
 - Access to an AWS account
 - Installed locally:
   - Docker
@@ -17,6 +18,7 @@ The following pre-requisites are necessary to work on the content:
 ## Create a work branch
 
 The first step is to create a working branch to create the content. There are two ways to do this depending on your access level:
+
 1. If you have `write` access to this repository you can clone it locally create a new branch directly
 2. Otherwise fork the repository, clone it and create a new branch
 
@@ -59,10 +61,12 @@ If the component you require is not already supported by EKS Blueprints you can
 In order to keep up with new versions of Helm charts being published there is an automated mechanism used to monitor all Helm charts used in the workshop content that will raise PRs when new versions are published.
 
 In addition to adding a component to Terraform as outlined in the previous section you must also do the following:
+
 - Edit the file `helm/charts.yaml` and specify the Helm repository, chart name etc.
 - Edit the file `terraform/modules/cluster/helm_versions.tf.json` and specify the initial version, note the map name must match the `name` field from `charts.yaml` for your chart.
 
 By default the automated system will look for the latest version of any charts added, but you can control this by using the `constraint` field, which uses the [NPM semantic versioning](https://docs.npmjs.com/about-semantic-versioning) constraint syntax. Please use this sparingly, as any constraints used will require additional maintenance overhead to keep updated. This should mainly be used for charts where:
+
 - The latest chart versions are incompatible with the version of EKS in the content
 - The content requires significant changes to bring it inline with a new version
 
@@ -82,6 +86,7 @@ Example constraint in `helm/charts.yaml`:
 Any content changes are expected to be accompanied by the any corresponding infrastructure changes in the same Pull Request.
 
 All Terraform configuration resides in the `terraform` directory, and is structured as follows:
+
 - `modules/cluster` contains resources related to VPC, EKS and those used by workloads in EKS (IAM roles)
 - `modules/ide` contains resources related to the Cloud9 IDE and its bootstrapping
 - `cluster-only` is a small wrapper around `modules/cluster`
@@ -122,17 +127,20 @@ make destroy-infrastructure
 When in the process of creating the content its likely you'll need to be fairly interactive in testing commands etc. For this theres a mechanism to easily create an interactive shell with access to the EKS cluster created by the Terraform, as well as including all the necessary tools and utilities without installing them locally.
 
 To use this utility you must:
+
 - Already have created the workshop infrastructure as outlined in the section above
 - Have some AWS credentials available in your current shell session (ie. you `aws` CLI must work)
 
 The shell session created will have AWS credentials injected, so you will immediately be able to use the `aws` CLI and `kubectl` commands with no further configuration:
 
 If using [finch CLI](https://github.com/runfinch/finch) instead of `docker` CLI you need to set two environment variable `CONTAINER_CLI` or run `make` with the variable set like `CONTAINER_CLI=finch make shell` here how to set the variable in the terminal session for every command.
+
 ```bash
 export CONTAINER_CLI=finch
 ```
 
 Run the `make shell`
+
 ```bash
 ➜  eks-workshop-v2 git:(main) ✗ make shell
 bash hack/shell.sh

diff --git a/docs/automated_tests.md b/docs/automated_tests.md
@@ -11,6 +11,7 @@ This section documents running the tests locally as well as via PRs.
 You should run the tests locally before raising a PR, this can be done with some convenience scripts.
 
 To use this utility you must:
+
 - Have some AWS credentials available in your current shell session (ie. you `aws` CLI must work)
 
 First, ensure you have the workshop infrastructure running in your AWS account:
@@ -105,6 +106,7 @@ make destroy-infrastructure
 **Note:** This section is for repository maintainers
 
 By default the end-to-end tests will not run against a PR because:
+
 - The PR should be reviewed first
 - Tests take time to execute so only selective modules should be run
 
@@ -226,14 +228,13 @@ $ sleep 150
 
 Here is a complete list of the available annotations:
 
-| Annotation  | Description  | Default |
-|-------------|--------------|---------|
-| test        | This script block should be executed as a test                                                                                                                                        | true    |
-| timeout     | Time limit in seconds before the script block will be marked as failed                                                                                                                | 120     |
-| hook        | Name of the hook to execute for this script section                                                                                                                                   |         |
-| hookTimeout | Time limit in seconds for the hooks to complete before the script block will be marked as failed                                                                                      | 300     |
-| expectError | Ignore any errors that occur when the script block is executed                                                                                                                        | false   |
-
+| Annotation  | Description                                                                                      | Default |
+| ----------- | ------------------------------------------------------------------------------------------------ | ------- |
+| test        | This script block should be executed as a test                                                   | true    |
+| timeout     | Time limit in seconds before the script block will be marked as failed                           | 120     |
+| hook        | Name of the hook to execute for this script section                                              |         |
+| hookTimeout | Time limit in seconds for the hooks to complete before the script block will be marked as failed | 300     |
+| expectError | Ignore any errors that occur when the script block is executed                                   | false   |
 
 ### What if my module can't be tested?
 

diff --git a/docs/cluster_requirements.md b/docs/cluster_requirements.md
@@ -5,12 +5,14 @@ The workshop provides multiple ways to provision the EKS cluster for the lab exe
 ## Global Requirements
 
 The following global requirements must be implemented:
+
 1. The configuration should be parameterized so that the infrastructure can be installed multiple times in the same AWS account/region
 2. All infrastructure should be tagged with `created-by: eks-workshop-v2` and `env: ${EKS_CLUSTER_NAME}`
 
 ## VPC
 
 The VPC for the lab cluster must implement the following:
+
 1. The default VPC CIDR should be `10.42.0.0/16`
 2. It should have 3 public subnets and 3 private subnets across different availability zones
 3. The public subnet CIDR ranges should be `10.42.0.0/19`, `10.42.32.0/19` and `10.42.64.0/19`
@@ -22,11 +24,12 @@ The VPC for the lab cluster must implement the following:
 ## EKS Cluster
 
 The EKS cluster for the lab must implement the following:
+
 1. It should have both public and private EKS control plane endpoints enabled
 2. It should have the VPC CNI EKS Managed Addon installed with the following configuration: `{"env":{"ENABLE_PREFIX_DELEGATION":"true", "ENABLE_POD_ENI":"true", "POD_SECURITY_GROUP_ENFORCING_MODE":"standard"}}`
 3. It should have a single node group, if possible named `default` with the following characteristics:
-    * Desired + Minimum size = 3, Maximum size = 6
-    * Instance type of `m5.large`
-    * Utilizing only the private subnets
-    * An AMI release version explicitly specified that matches the other implementations
-    * The label `workshop-default: 'yes'`
+   - Desired + Minimum size = 3, Maximum size = 6
+   - Instance type of `m5.large`
+   - Utilizing only the private subnets
+   - An AMI release version explicitly specified that matches the other implementations
+   - The label `workshop-default: 'yes'`
diff --git a/docs/eks_version_upgrades.md b/docs/eks_version_upgrades.md
@@ -28,6 +28,7 @@ The name of the release expected by the EKS API for this AMI would be:
 ```
 
 This is a combination of:
+
 - the `k8s` value (`1.25.6`)
 - the date string without the `v` (`20230304`)
 
@@ -39,4 +40,4 @@ There are various places that reference the Kubernetes versions (Kubernetes, kub
 1. IDE installer: `lab/scripts/installer.sh`
 1. eksctl: `cluster/eksctl/cluster.yaml`
 1. Terraform: `cluster/terraform/variables.tf`
-1. Common kubectl: `hack/lib/kubectl-version.sh`
+1. Common kubectl: `hack/lib/kubectl-version.sh`
diff --git a/docs/faq.md b/docs/faq.md
@@ -6,15 +6,15 @@ The error looks similar to this:
 
 ```
 │ Error: could not download chart: failed to download "oci://public.ecr.aws/kubecost/cost-analyzer" at version "1.96.0"
-│ 
+│
 │   with module.cluster.module.eks-blueprints-kubernetes-addons.module.kubecost[0].module.helm_addon.helm_release.addon[0],
 │   on .terraform/modules/cluster.eks-blueprints-kubernetes-addons/modules/kubernetes-addons/helm-addon/main.tf line 1, in resource "helm_release" "addon":
 │    1: resource "helm_release" "addon" {
-│ 
+│
 ╵
 ```
 
-This is likely due to expired credentials from previously interacting with ECR Public. 
+This is likely due to expired credentials from previously interacting with ECR Public.
 Run `docker logout public.ecr.aws`, `helm registry logout public.ecr.aws` and then re-run `make create-infrastructure`.
 
 ### Q: Destroying my infrastructure failed and now I have AWS resources left over, what can I do?

diff --git a/docs/releases.md b/docs/releases.md
@@ -1,6 +1,6 @@
 # EKS Workshop - Releases
 
-The EKS Workshop will publish a new version on the last Friday of each month containing all PRs merged to the `main` branch during that time. This will update the content on https://eksworkshop.com and publish a new version to Workshop Studio for AWS events. The changes for the release each month will be publish as a GitHub Release with a corresponding changelog. 
+The EKS Workshop will publish a new version on the last Friday of each month containing all PRs merged to the `main` branch during that time. This will update the content on https://eksworkshop.com and publish a new version to Workshop Studio for AWS events. The changes for the release each month will be publish as a GitHub Release with a corresponding changelog.
 
 There may be releases published off-schedule for specific events like re:Invent and Kubecon, as well as updates made during the month for critical bug fixes.
 
@@ -9,6 +9,7 @@ Each release will have a corresponding GitHub milestone associated with it to tr
 ## Milestones
 
 GitHub allows the associating of both issues and pull requests to milestones for tracking. In general the pattern for this repository is:
+
 1. Associate with an issue if it exists while PR is being developed
 2. Replacing the issue with the PR in the milestone once created
 
@@ -28,12 +29,12 @@ feat: This is my pull request
 
 The following types will be recognized by the release notes generator:
 
-| Type        | Release Notes Section | Purpose                                                                                    |
-| ----------- | --------------------- | ------------------------------------------------------------------------------------------ |
-| new         | New labs              | A net-new lab has been added in this PR                                                    |
-| update      | Updated labs          | The content of an existing lab has changed                                                 |
-| fix         | Fixes                 | A simple fix that has not changed the flow/structure of a lab                              |
-| feat        | Features              | Adds or updates functionality not related to a specific lab (for example website, testing) |
+| Type   | Release Notes Section | Purpose                                                                                    |
+| ------ | --------------------- | ------------------------------------------------------------------------------------------ |
+| new    | New labs              | A net-new lab has been added in this PR                                                    |
+| update | Updated labs          | The content of an existing lab has changed                                                 |
+| fix    | Fixes                 | A simple fix that has not changed the flow/structure of a lab                              |
+| feat   | Features              | Adds or updates functionality not related to a specific lab (for example website, testing) |
 
 The generator will also pick up `content/` labels applied to the PRs to categorize PRs according to the top level module that they are related to. For example `content/security` would result in:
 
@@ -46,6 +47,7 @@ This is not relevant to all PRs so only use this capability where it makes sense
 ## Triggering a release
 
 Closing a milestone will automatically trigger its corresponding release process through GitHub actions. This will:
+
 1. Generate release notes
 2. Create a tag prefixed with `release-`
-3. Create a GitHub release referencing (1) and (2)
+3. Create a GitHub release referencing (1) and (2)
diff --git a/docs/reviewer_checklist.md b/docs/reviewer_checklist.md
@@ -33,4 +33,4 @@ See style guide for expanded explanations.
 ## Misc
 
 - [ ] Generated lab timing has been created (new lab) or updated (updated lab) if needed
-- [ ] All Terraform resources created have dynamic names
+- [ ] All Terraform resources created have dynamic names
diff --git a/docs/style_guide.md b/docs/style_guide.md
@@ -122,7 +122,7 @@ $ kubectl exec -it deployment/example -- bash
 [root@b32a35acd6b6 /]$ curl localhost:8080
 Hello!
 [root@b32a35acd6b6 /]$ exit
-$ 
+$
 ```
 
 It is preferable to use this:
@@ -141,7 +141,6 @@ Sometimes it is tempting to execute a long-running command in one window and ins
 2. Contextual information like environment variables can get lost in new windows
 3. It is more difficult to test
 
-
 ### Referencing external manifests or components
 
 If something like a manifest hosted externally is to be referenced by content it should be pinned as explicitly as possible to prevent changes to these files causing uncontrolled changes to the content experience, or worse breaking it entirely.
@@ -165,6 +164,7 @@ Notice we changed from referring to `master` to referring to the tag `v0.0.86`.
 ### Referencing existing AWS infrastructure in content
 
 It is common in workshop content to reference various AWS infrastructure that has been build by the Terraform configuration provided. Some examples of this include:
+
 - Getting the cluster name to reference in a Kubernetes manifest
 - Modifying EKS managed node group configuration by name
 
@@ -195,6 +195,7 @@ Note blocks are available
 ### Badges
 
 To mark your module as an independent module that users can begin with, place the following in the header of your markdown file:
+
 ```
 ---
 ...
@@ -203,6 +204,7 @@ sidebar_custom_props: {"module": true}
 ```
 
 To mark your module as informational, with no actionable steps, place the following in the header of your markdown file:
+
 ```
 ---
 ...

diff --git a/docs/ui_components.md b/docs/ui_components.md
@@ -9,6 +9,7 @@ Docusaurus provides the framework for building the front-end of the workshop con
 The terminal window component is designed to display commands that participants should run, as well as optionally it associated output.
 
 It provides the following features:
+
 - Supports multi-line commands using `\`
 - Scrolls for content too large to display
 - 'Click to copy' function which copies the command to the clipboard when clicking anywhere on the component (ignoring output)