docs: Add GitHub pages

.github/workflows/website-deploy.yml

@@ -0,0 +1,44 @@
+name: website-deploy-to-github-pages
+
+on:
+  push:
+    branches:
+      - main
+    # Review gh actions docs if you want to further define triggers, paths, etc
+    # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on
+
+jobs:
+  deploy:
+    name: Deploy to GitHub Pages
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        shell: bash
+        working-directory: website
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 18
+          cache: npm
+          cache-dependency-path: website/package-lock.json
+      - name: Install dependencies
+        run: npm ci
+      - name: Build website
+        run: npm run build
+
+      # Popular action to deploy to GitHub Pages:
+      # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
+      - name: Deploy to GitHub Pages
+        uses: peaceiris/actions-gh-pages@v3
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          # Build output to publish to the `gh-pages` branch:
+          publish_dir: ./website/build
+          # The following lines assign commit authorship to the official
+          # GH-Actions bot for deploys to `gh-pages` branch:
+          # https://github.com/actions/checkout/issues/13#issuecomment-724415212
+          # The GH actions bot is used by default if you didn't specify the two fields.
+          # You can swap them out with your own user credentials.
+          user_name: github-actions[bot]
+          user_email: github-actions[bot]@users.noreply.github.com

.github/workflows/website-test-deploy.yml

@@ -0,0 +1,27 @@
+name: website-test-deployment
+
+on:
+  pull_request:
+    branches:
+      - main
+
+jobs:
+  test-deploy:
+    name: Test deployment
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        shell: bash
+        working-directory: website
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 18
+          cache: npm
+          cache-dependency-path: website/package-lock.json
+
+      - name: Install dependencies
+        run: npm ci
+      - name: Test build website
+        run: npm run build

docs/public/README.md

@@ -221,7 +221,7 @@ Let's take a moment and dissect this object.
 | **environmentStringVariablesFromIncomingEvent** | string[]                                                                                              | The environment variables to import into the ScriptJob from event details field.                                   |
 | **environmentVariablesToOutgoingEvent**         | string[]                                                                                              | The environment variables to export into the outgoing event once the ScriptJob has finished.                       |
 | **scriptEnvironmentVariables**                  | `{ [key: string]: string }`                                                                           | The variables to pass into the codebuild ScriptJob.                                                                |
-| **eventManager**                                | [IEventManager](/API.md#ieventmanager-)                                                               | The EventManager instance that allows connecting to events flowing between the Control Plane and other components. |
+| **eventManager**                                | [IEventManager](https://github.com/awslabs/sbt-aws/blob/main/API.md#eventmanager-)                    | The EventManager instance that allows connecting to events flowing between the Control Plane and other components. |
 
 The heavy lifting of the `ScriptJob` construct (along with constructs that extend it like `ProvisioningScriptJob`) happens with the value of the `script` key. Let's take a look at the example provisioning script now:
 

website/.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

website/README.md

@@ -0,0 +1,41 @@
+# Website
+
+This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
+
+### Installation
+
+```
+$ yarn
+```
+
+### Local Development
+
+```
+$ yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+### Build
+
+```
+$ yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+### Deployment
+
+Using SSH:
+
+```
+$ USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```
+$ GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

website/babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

website/docs/partners/intro.md

@@ -0,0 +1,4 @@
+---
+sidebar_position: 1
+---
+# PARTNER STUFF

website/docs/point_solutions/intro.md

@@ -0,0 +1,4 @@
+---
+sidebar_position: 1
+---
+# POINT SOLUTION STUFF

website/docs/point_solutions/token-vending-machine/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Token Vending Machine",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Generate and assume temporary tenant-specific credentials"
+  }
+}

website/docs/point_solutions/token-vending-machine/token-vending-machine.md

@@ -0,0 +1,45 @@
+---
+sidebar_position: 1
+---
+
+# Intent
+
+* Provide an overview of the purpose and functionality of the pattern
+* One paragraph with two or three lines will be enough for this section 
+
+# Motivation
+
+* Highlight the challenges where this pattern will be useful for the developers.
+* Provide as much details as possible. You can go upto six paragraphs 
+
+# Applicability
+
+* If there are any specific situations where this pattern can be more applicable, highlight them here 
+* One line bullet points should be fine for this section 
+
+# Issues and considerations
+
+* Highlight the issues and things to consider before someone adopts and start using this pattern
+* Highlight each issue in a separate bullet point and expand with details
+
+# Implementation
+
+## High-level architecture
+
+* Provide a high level architecture for this patterns with diagrams and explanation
+
+## Implementation using AWS services
+
+* Showcase sample implementation architecture using AWS services icons in the architecture diagram and provide explanation 
+
+## Sample Code
+
+* If there’s any sample code that you want to highlight, add it to this section - This is optional
+
+# GitHub repository
+
+For a complete implementation of the sample architecture for this pattern, see the GitHub repository at * If there is a github repository for this pattern, provide a link to the repo 
+
+# Blog references
+
+* Provide links to any blogs that you want to cross reference with this pattern - This is optional

website/docs/tutorials/intro.md

@@ -0,0 +1,31 @@
+---
+sidebar_position: 1
+---
+
+# Tutorial Intro
+
+This tutorial will walk you through creating a basic multi-tenant application using SaaS
+Builder Toolkit. 
+
+## Introduction
+
+
+
+### What you'll need
+
+- [Node.js](https://nodejs.org/en/download/) version 18.0 or above:
+  - When installing Node.js, you are recommended to check all checkboxes related to dependencies.
+- [AWS Cloud Development Kit](https://aws.amazon.com/cdk/) version XX or above:
+  - Directions for installing are [here](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_install)
+
+## Step 1: CDK getting started
+
+Follow the instructions in CDK's getting started guide. This guide walks you through installing the pre-requisites
+and ensuring your environment is prepared to build your first CDK app.
+
+## Step 2: Hello SBT!
+
+Follow the instructions in [**Step One** of CDK's "Hello CDK" project](https://docs.aws.amazon.com/cdk/v2/guide/hello_world.html#hello_world_create).
+
+You don't have to build or deploy the project, just initialize a new empty project. Once done, come back here,
+and we'll get started with building your first SBT-enabled multi-tenant app.

website/docs/tutorials/tutorial-basics/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "SBT Tutorial - Basics",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Use SBT to build and deploy a multi-tenant application."
+  }
+}

website/docs/tutorials/tutorial-basics/app-plane-utils.md

@@ -0,0 +1,69 @@
+---
+sidebar_position: 5
+---
+
+# Application plane utilities
+
+Although entirely optional, SBT includes a utility that lets you define, and run arbitrary jobs upon receipt of a control plane message, called a `ScriptJob`. This mechanism is extended to produce two new helper constructs `ProvisioningScriptJob` and `DeprovisioningScriptJob` which are used for onboarding and off-boarding, respectively, in the reference architectures which were ported to SBT (see references at the end of this document). That tenant provisioning/deprovisioning process is depicted below:
+
+![sbt-provisioning.png](/img/sbt-provisioning.png)
+
+Notice the use of the `provisioning.sh` and `deprovisioning.sh` scripts at the top. These scripts are fed to the `ProvisioningScriptJob` and `DeprovisioningScriptJob` as parameters. Internally the `ScriptJob` launches an AWS `CodeBuild` project, wrapped inside an AWS Step Function, to execute the bash scripts. The `ScriptJob` also lets you specify what input variables to feed to the scripts, along with what output variables you expect them to return. Note that in this version of SBT, you can create the `ScriptJob` construct with `ScriptJobProps` and configure `CoreAppPlane` with `ScriptJobs` using its `scriptJobs` property. The `CoreAppPlane` will then link these `ScriptJobs` to EventBridge. Let's take a simple example: imagine our SaaS application deployed only a single S3 bucket per tenant. Let's create a `ProvisioningScriptJob` for that provisioning now:
+
+```typescript
+const scriptJobProps: TenantLifecycleScriptJobProps = {
+  permissions: PolicyDocument.fromJson(/*See below*/),
+  script: '' /*See below*/,
+  environmentStringVariablesFromIncomingEvent: ['tenantId', 'tier'],
+  environmentVariablesToOutgoingEvent: ['tenantS3Bucket', 'someOtherVariable', 'tenantConfig'],
+  scriptEnvironmentVariables: {
+    TEST: 'test',
+  },
+  eventManager: eventManager /*See below on how to create EventManager*/,
+};
+```
+
+| Key                                             | Type                                                                                                  | Purpose                                                                                                            |
+| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| **script**                                      | string                                                                                                | A string in bash script format that represents the job to be run (example below)                                   |
+| **permissions**                                 | [PolicyDocument](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_iam.PolicyDocument.html) | An IAM policy document giving this job the IAM permissions it needs to do what it's being asked to do              |
+| **environmentStringVariablesFromIncomingEvent** | string[]                                                                                              | The environment variables to import into the ScriptJob from event details field.                                   |
+| **environmentVariablesToOutgoingEvent**         | string[]                                                                                              | The environment variables to export into the outgoing event once the ScriptJob has finished.                       |
+| **scriptEnvironmentVariables**                  | `{ [key: string]: string }`                                                                           | The variables to pass into the codebuild ScriptJob.                                                                |
+| **eventManager**                                | [IEventManager](https://github.com/awslabs/sbt-aws/blob/main/API.md#eventmanager-)                    | The EventManager instance that allows connecting to events flowing between the Control Plane and other components. |
+
+The heavy lifting of the `ScriptJob` construct (along with constructs that extend it like `ProvisioningScriptJob`) happens with the value of the script key. Let's take a look at the example provisioning script now:
+
+```typescript
+echo "starting..."
+
+# note that this template.json is being created here, but
+# it could just as easily be pulled in from an S3 bucket.
+cat > template.json << EOM
+{
+  "AWSTemplateFormatVersion": "2010-09-09",
+  "Resources": {"MyBucket": {"Type": "AWS::S3::Bucket"}},
+  "Outputs": {"S3Bucket": {"Value": { "Ref": "MyBucket" }}}
+}
+EOM
+
+echo "tenantId: $tenantId"
+echo "tier: $tier"
+
+aws cloudformation create-stack --stack-name "tenantTemplateStack-\${tenantId}"  --template-body "file://template.json"
+
+aws cloudformation wait stack-create-complete --stack-name "tenantTemplateStack-\${tenantId}"
+
+export tenantS3Bucket=$(aws cloudformation describe-stacks --stack-name "tenantTemplateStack-\${tenantId}" | jq -r '.Stacks[0].Outputs[0].OutputValue')
+export someOtherVariable="this is a test"
+echo $tenantS3Bucket
+export tenantConfig=$(jq --arg SAAS_APP_USERPOOL_ID "MY_SAAS_APP_USERPOOL_ID" \
+--arg SAAS_APP_CLIENT_ID "MY_SAAS_APP_CLIENT_ID" \
+--arg API_GATEWAY_URL "MY_API_GATEWAY_URL" \
+-n '{"userPoolId":$SAAS_APP_USERPOOL_ID,"appClientId":$SAAS_APP_CLIENT_ID,"apiGatewayUrl":$API_GATEWAY_URL}')
+
+echo $tenantConfig
+export tenantStatus="created"
+
+echo "done!"
+```

website/docs/tutorials/tutorial-basics/build-it.md

@@ -0,0 +1,43 @@
+---
+sidebar_position: 3
+---
+
+# Build the control plane
+
+Now let's build and deploy this component. Before we do, we have to modify one other file. Open up the `hello-cdk.ts` file in the bin directory, and replace everything that's in there with the following contents:
+
+```typescript
+#!/usr/bin/env node
+import 'source-map-support/register';
+import * as cdk from 'aws-cdk-lib';
+import { ControlPlaneStack } from '../lib/control-plane';
+// import { AppPlaneStack } from '../lib/app-plane';
+
+const app = new cdk.App();
+const controlPlaneStack = new ControlPlaneStack(app, 'ControlPlaneStack');
+// const appPlaneStack = new AppPlaneStack(app, 'AppPlaneStack', {
+//   eventManager: controlPlaneStack.eventManager,
+// });
+```
+
+Notice we're leaving a few lines commented out here, we'll come back to those later when we discuss the application plane. Ensure everything is saved, then from the root of your hello-cdk project, run the following:
+
+:::warning
+Because our control plane deploys Lambda functions, you'll need Docker installed to build and deploy this CDK stack
+:::
+
+```bash
+npm run build
+cdk bootstrap
+cdk deploy ControlPlaneStack
+```
+
+This will kick of the synthesis of your CDK application to AWS CloudFormation, then deploy that CloudFormation. Behind the scenes, a lot is getting created. This construct not only stands up the surface of our control plane API, using a new API Gateway component, it also deploys several services as AWS Lambda functions used for tenant provisioning and management.
+
+Feel free to open your AWS Console and take a look at the following (ensure you're in the same region you deployed to):
+
+* [AWS Lambda](https://console.aws.amazon.com/lambda/home)
+* [Amazon Cognito](https://console.aws.amazon.com/cognito/v2/idp/user-pools)
+* [API Gateway](https://console.aws.amazon.com/apigateway/main/apis)
+
+Once done, we now have the left side of our conceptual diagram deployed, and we did it with just a few constructs. It deployed not only the API surface of our control plane, but also wired it up to EventBridge. Next, we'll start deploy the application plane, and connect it to the same EventBridge bus, so we can act upon those control plane messages.

website/docs/tutorials/tutorial-basics/congratulations.md

@@ -0,0 +1,6 @@
+---
+sidebar_position: 9
+---
+
+# Congratulations!
+