Edit docs CI workflows to accommodate Docusaurus (#48388)

* Edit docs CI workflows to accommodate Docusaurus

- Copy the `gravitational/teleport` source into the `content` directory
  of a `gravitational/docs-website` clone and overwrite the `git-update`
  yarn script with a no-op command. With way, we can use the
  `gravitational/teleport` clone across multiple workflow steps (e.g.,
  the prose linting step), and can identify a branch to pull using the
  `actions/checkout` defaults. Name the submodule directory `current` to
  match the expectations of the Docusaurus site.

- Remove the Vercel preview workflow. After the docs engine migration,
  we'll no longer need to deploy a preview to Vercel in order to show
  docs authors what their potential changes look like on a rendered docs
  site.

Also fixes spelling errors caught by a later version of cspell.

* Fix shellcheck issues in doc-tests.yaml script

- Add `exit` commands for failed `cd`s
- Don't read from and write to `package.json` in the same pipeline
- Add double quotes around variables

* Use latest Docusaurus site config schema

* Fix the Prepare docs site configuration step

- Remove unneeded `cd`s
- Use the correct version name in the `config.json` prepared for the
  Docusaurus site

.github/workflows/doc-tests.yaml

@@ -50,7 +50,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
         with:
-          repository: 'gravitational/docs'
+          repository: 'gravitational/docs-website'
           path: 'docs'
 
       # Cache node_modules. Unlike the example in the actions/cache repo, this
@@ -80,30 +80,35 @@ jobs:
         # use for the live docs site in that we only test a single version of
         # the content.
         #
-        # To do this, we replace the three submodules we use for building the
-        # live docs site with a single submodule, pointing to the
-        # gravitational/teleport branch we are linting.
-        #
+        # To do this, we delete the three submodules we use for building the
+        # live docs site and copy a gravitational/teleport clone into the
+        # content directory.
+        # 
         # The docs engine expects a config.json file at the root of the
         # gravitational/docs clone that associates directories with git
         # submodules. By default, these directories represent versioned branches
         # of gravitational/teleport. We override this in order to build only a
         # single version of the docs.
+        #
+        # We also replace data fetched from Sanity CMS with hardcoded JSON
+        # objects to remove the need to authenticate with Sanity. Each includes
+        # the minimal set of data required for docs builds to succeed.
         run: |
           echo "" > .gitmodules
           rm -rf content/*
-          cd content
           # Rather than using a submodule, copy the teleport source into the
           # content directory.
-          cp -r $GITHUB_WORKSPACE/teleport $GITHUB_WORKSPACE/docs/content
-          cd $GITHUB_WORKSPACE/docs
-          echo "{\"versions\": [{\"name\": \"teleport\", \"branch\": \"teleport\", \"deprecated\": false}]}" > $GITHUB_WORKSPACE/docs/config.json
-          cat <<< "$(jq '.scripts."git-update" = "echo Skipping submodule update"' package.json)" > package.json
-          yarn build-node
+          cp -r "$GITHUB_WORKSPACE/teleport" "$GITHUB_WORKSPACE/docs/content/current"
+          jq -nr --arg version "current" '{"versions": [{"name": $version,"branch": $version,"deprecated": false,"isDefault": true}]}' > config.json
+          NEW_PACKAGE_JSON=$(jq '.scripts."git-update" = "echo Skipping submodule update"' package.json);
+          NEW_PACKAGE_JSON=$(jq '.scripts."prepare-sanity-data" = "echo Using pre-populated Sanity data"' <<< "$NEW_PACKAGE_JSON");
+          echo "$NEW_PACKAGE_JSON" > package.json;
+          echo "{}" > data/events.json
+          echo '{"bannerButtons":{"second":{"title":"LOG IN","url":"https://teleport.sh"},"first":{"title":"Support","url":"https://goteleport.com/support/"}},"navbarData":{"rightSide":{},"logo":"/favicon.svg","menu":[]}}' > data/navbar.json
 
       - name: Check spelling
         working-directory: 'docs'
-        run: yarn spellcheck content/teleport
+        run: yarn spellcheck content/current
 
       - name: Lint docs formatting
         working-directory: 'docs'

docs/cspell.json

@@ -2,6 +2,14 @@
   "language": "en",
   "version": "0.2",
   "words": [
+    "aada",
+    "abee",
+    "fffc",
+    "fabfc",
+    "microservices",
+    "configmaps",
+    "genrsa",
+    "displayname",
     "AADUSER",
     "ABCDEFGHIJKL",
     "ADFS",

docs/pages/enroll-resources/application-access/guides/connecting-apps.mdx

@@ -132,10 +132,9 @@ Teleport, you must configure these yourself:
      Service domain, e.g., `*.teleport.example.com`, with the domain name of the
      Teleport Proxy Service.
 
-1. Ensure that your system provisionings TLS certificates for
-   Teleport-registered applications. The method to use depends on how you
-   originally set up TLS for your self-hosted Teleport deployment, and is
-   outside the scope of this guide. 
+1. Ensure that your system provisions TLS certificates for Teleport-registered
+   applications. The method to use depends on how you originally set up TLS for
+   your self-hosted Teleport deployment, and is outside the scope of this guide. 
 
    In general, the same system that provisions TLS certificates signed for the
    web address of the Proxy Service (e.g., `teleport.example.com`) must also

docs/pages/reference/resources.mdx

@@ -126,7 +126,7 @@ When no `kubernetes_resource` is set:
 {/* This table is cursed. Our current docs engine doesn't support HTML tables
 (due to SSR and the rehydration process). We have dto do everything inlined in
 markdown. Some HTML character codes are used to render specific chars like {}
-or to avoid line breaks in the middle fo the YAML. Whitespaces before br tags
+or to avoid line breaks in the middle fo the YAML. Spaces before br tags
 are required.*/}
 
 | Allow rule                                                                                                                                                                                                                                                                | Role v5                                                                                                           | Role v6                                                                                                           | Role v7                                                                                                                                                                                               |

docs/pages/reference/signature-algorithms.mdx

@@ -192,8 +192,8 @@ in each suite.
 Try it and let us know!
 We aim to balance security, performance, and compatibility with the chosen
 signature algorithm suites.
-It is okay to continue using the `legacy` suite for the forseeable future and we
-expect it may be required for some user's environments.
+It is okay to continue using the `legacy` suite for the foreseeable future and we
+expect it may be required for some users' environments.
 
 ### How did you choose these algorithms?