feat: move website to public repo

.github/workflows/ci.yml

@@ -7,16 +7,47 @@ on:
       - main
     tags:
       - "v*.*.*"
+    paths-ignore:
+      - 'website/**'
   pull_request:
     branches:
       - main
+    paths-ignore:
+      - 'website/**'
 
 env:
   MAIN_BRANCH: ${{ 'refs/heads/main' }}
 
 jobs:
+  # Check if we should skip CI if only ./website directory was modified
+  check_skip_condition:
+    name: Check if CI should be skipped
+    runs-on: ubuntu-latest
+    outputs:
+      run_workflow: ${{ steps.check.outputs.run_workflow }}
+    steps:
+      - uses: actions/checkout@v3
+        with:
+          fetch-depth: 0  # fetches all history for all branches and tags
+      - name: Check for changes outside website directory
+        id: check
+        run: |
+          if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
+            # On main branch, compare the latest commit with its parent
+            diff_base="HEAD^"
+          else
+            # On other branches or PRs, compare with the main branch
+            diff_base="origin/main"
+          fi
+          if git diff --name-only $diff_base HEAD | grep -v -e '^website/' | grep -q '^'; then
+            echo "run_workflow=true" >> $GITHUB_OUTPUT
+          else
+            echo "run_workflow=false" >> $GITHUB_OUTPUT
+          fi
   check_nix:
     name: Basic Check
+    needs: check_skip_condition
+    if: needs.check_skip_condition.outputs.run_workflow == 'true'
     runs-on: ubuntu-22.04
     steps:
       - name: git checkout
@@ -42,7 +73,7 @@ jobs:
         run: |
           git reset --hard
           git clean -f
-          nix develop --command go-tidy-all 
+          nix develop --command go-tidy-all
           export changed_files=$(git diff-files --name-only | grep -cv ".toml$")
           if [[ $changed_files != 0 ]]; then
             echo "Go modules are not so tidy (run 'go-tidy-all' to fix it):"
@@ -58,7 +89,8 @@ jobs:
 
   build_publish_images:
     name: Test, build and publish images
-    needs: check_nix
+    needs: [check_skip_condition, check_nix]
+    if: needs.check_skip_condition.outputs.run_workflow == 'true'
     runs-on: ubuntu-22.04
     steps:
       - name: git checkout
@@ -100,7 +132,8 @@ jobs:
 
   build_clis:
     name: Test and build cross-compiled clis
-    needs: check_nix
+    needs: [check_skip_condition, check_nix]
+    if: needs.check_skip_condition.outputs.run_workflow == 'true'
     runs-on: ubuntu-22.04
     strategy:
       matrix:

.github/workflows/publish-demo-artifacts.yml

@@ -6,9 +6,6 @@ on:
       - main
     tags:
       - "v*.*.*"
-  pull_request:
-    branches:
-      - main
 
 jobs:
   build-publish-demo:

website/.env.development

@@ -0,0 +1,17 @@
+// these vars are the same as prod other than the segment write key
+NEXT_PUBLIC_SEGMENT_WRITE_KEY=$SEGMENT_WRITE_KEY
+NEXT_PUBLIC_GTM_ID="G-4ED2CBQW28"
+NEXT_PUBLIC_MAILCHIMP_POST_URL="https://kurtosistech.us2.list-manage.com/subscribe/post?u=f5abda98cffb3b5cabc61fec3&id=a84b217399&f_id=0063f0e3f0"
+
+// If we make major revisions to our landing pages, we can increment this so that analytics
+// in Segment are easier to compare by version
+NEXT_PUBLIC_LANDING_PAGE_VERSION="2"
+NEXT_PUBLIC_CF_PAGES_COMMIT_SHA="local"
+
+// Docs voting API: from https://github.com/kurtosis-tech/docs-voting/tree/main
+
+// URL for docs voting feature: LOCALHOST
+// NEXT_PUBLIC_DOCS_VOTING_API="http://localhost:9111"
+
+// URL for docs voting feature: PROD
+NEXT_PUBLIC_DOCS_VOTING_API="https://voting.kardinal.dev:9111"

website/.env.production

@@ -0,0 +1,14 @@
+// Sourced from Cloudflare Pages env
+NEXT_PUBLIC_SEGMENT_WRITE_KEY=$SEGMENT_WRITE_KEY
+NEXT_PUBLIC_GTM_ID="G-4ED2CBQW28"
+NEXT_PUBLIC_MAILCHIMP_POST_URL="https://kurtosistech.us2.list-manage.com/subscribe/post?u=f5abda98cffb3b5cabc61fec3&id=0f00aab6f2&f_id=00acf0e3f0"
+
+// If we make major revisions to our landing pages, we can increment this so that analytics
+// in Segment are easier to compare by version
+NEXT_PUBLIC_LANDING_PAGE_VERSION="2"
+
+// https://developers.cloudflare.com/pages/configuration/build-configuration/#environment-variables
+NEXT_PUBLIC_CF_PAGES_COMMIT_SHA=$CF_PAGES_COMMIT_SHA
+
+// URL for docs voting feature
+NEXT_PUBLIC_DOCS_VOTING_API="https://voting.kardinal.dev:9111"

website/.eslintrc.json

@@ -0,0 +1,23 @@
+{
+  "extends": ["eslint:recommended", "next/core-web-vitals"],
+  "rules": {
+    "simple-import-sort/imports": [
+      "error",
+      {
+        "groups": [
+          ["^@?\\w"],
+          ["^(@|components|sections|src|$lib)(/.*|$)"],
+          ["^\\.\\.(?!/?$)", "^\\.\\./?$"],
+          ["^\\./(?=.*/)(?!/?$)", "^\\.(?!/?$)", "^\\./?$"],
+          ["^.+\\.s?css$"]
+        ]
+      }
+    ],
+    "simple-import-sort/exports": "error",
+    "react/react-in-jsx-scope": "off",
+    "react/jsx-uses-react": "off",
+    "no-irregular-whitespace": "off"
+  },
+  "plugins": ["simple-import-sort"],
+  "ignorePatterns": ["public/", ".next/", "out/"]
+}

website/.gitignore

@@ -0,0 +1,37 @@
+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
+
+# dependencies
+/node_modules
+/.pnp
+.pnp.js
+.yarn/install-state.gz
+
+# testing
+/coverage
+
+# next.js
+/.next/
+/out/
+
+# production
+./build
+!./app/build
+
+# misc
+.DS_Store
+*.pem
+
+# debug
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# local env files
+.env*.local
+
+# vercel
+.vercel
+
+# typescript
+*.tsbuildinfo
+next-env.d.ts

website/.husky/pre-commit

@@ -0,0 +1 @@
+bun run pre-commit

website/.lintstagedrc.js

@@ -0,0 +1,18 @@
+module.exports = {
+  // Type check TypeScript files
+
+  "**/*.(ts|tsx)": () => "bun tsc --noEmit",
+
+  // Lint & Prettify TS and JS files
+
+  "**/*.(ts|tsx|js)": (filenames) => [
+    `bun eslint ${filenames.join(" ")}`,
+
+    `bun prettier --write ${filenames.join(" ")}`,
+  ],
+
+  // Prettify only Markdown and JSON files
+
+  "**/*.(md|json)": (filenames) =>
+    `bun prettier --write ${filenames.join(" ")}`,
+};

website/.prettierignore

@@ -0,0 +1,3 @@
+.husky
+bun.lockb
+*.nix

website/README.md

@@ -0,0 +1,61 @@
+This is a [Next.js](https://nextjs.org/) project bootstrapped with [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app).
+
+## Requirements
+
+`nix` installed on your system, or `bun` installed globally if you prefer to not use `nix`
+
+## Getting Started
+
+Enter Nix shell environment
+
+```
+$ nix-shell
+```
+
+Install dependencies
+
+```
+[nix-shell]$ bun i
+```
+
+Run the development server:
+
+```bash
+[nix-shell]$ bun dev
+```
+
+Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
+
+You can start editing the page by modifying any file. The page auto-updates as you edit the file.
+
+## Deployment
+
+Pushes to the `main` branch are automatically deployed to Cloudflare Pages. The
+deployment dashboard can be found here:
+https://dash.cloudflare.com/8a3fd12f290cd3ecfdacccbbebf096c6/pages/view/kardinal-landing-page
+
+To ensure your code will build when pushed, build the entire app locally to ensure
+there are no typescript errors (currently the dev server only lazy-compiles
+pages that you load). This experience can be improved in the future.
+
+```
+[nix-shell]$ bun run build
+```
+
+If there are any errors, fix them before pushing. You can also auto-fix some
+linter errors:
+
+```
+[nix-shell]$ bun run lint:fix
+```
+
+## Learn More
+
+To learn more about Next.js, take a look at the following resources:
+
+- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
+- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
+
+You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js/) - your feedback and contributions are welcome!
+
+## Deploy

website/app/build/page.tsx

@@ -0,0 +1,31 @@
+import { Metadata } from "next";
+
+import LandingPageTemplate from "@/components/LandingPageTemplate";
+import Sparkle from "@/components/Sparkle";
+
+export const metadata: Metadata = {
+  title: "Kardinal",
+  description: "Develop in prod, fearlessly.",
+};
+
+const Page = () => {
+  return (
+    <LandingPageTemplate
+      heading={
+        <>
+          Develop in prod
+          <br />
+          <em>
+            Fearlessly
+            <Sparkle />
+          </em>
+        </>
+      }
+    >
+      Develop with production data, services,
+      <br data-desktop /> or traffic without the risk.
+    </LandingPageTemplate>
+  );
+};
+
+export default Page;

website/app/docs/architecture/overview/page.mdx

@@ -0,0 +1,22 @@
+export const metadata = {
+  title: "Kardinal Docs | Architecture",
+};
+
+# Architecture
+
+Kardinal is built with a sidecar - control plane architecture.
+
+There are two kinds of sidecars:
+
+- _Stateless service sidecar_
+
+  Deployed alongside services that are stateless, and thus can be reused across flows without risk of corrupting data in other flows.
+
+- _Stateful service sidecar_
+
+  Deployed alongside services that have state like databases, queues, and caches. Implements rules like “shared read, isolated write”, “isolated read, isolated write”, and “shared read/write” which allow the stateful service to be maximally reused across flows without breaking isolation.
+
+Both of these sidecars are deployed inside of your environment, next to the corresponding stateless or stateful services.
+
+The **control plane** is the single interface where the behavior of the Kardinal sidecars is managed. It enables developers to configure and monitor their [flows](concepts/flows) and [maturity gates](concepts/maturity-gates) for themselves and their organization.
+

website/app/docs/concepts/flows/page.mdx

@@ -0,0 +1,23 @@
+export const metadata = {
+  title: "Kardinal Docs | Flows",
+};
+
+# Flows
+
+In Kardinal, a “flow” is a set of traffic routing rules paired with a data isolation layer that achieves the appropriate levels of isolation and data exposure for a version of deployable software.
+
+Anything you do with an “environment” across the software delivery lifecycle can be done with a “flow” in Kardinal. For example:
+
+- Isolated Dev Sandbox → [Isolated Dev Flow](use-cases/isolated-dev-sandbox-flows)
+- Preview Environment → [Preview Flow](use-cases/preview-and-feature-branch-flows)
+- QA Environment → [QA Flow](use-cases/qa-flows)
+
+_Flows are possible because Kardinal links traffic routing/mirroring rules with data access and isolation policies_. When both are combined, you can effectively create virtual views over an environment (we call them flows) where both the traffic and the data that are sent through the flow are isolated to a particular workflow (dev, QA, staging).
+
+An example flow configuration looks like this:
+
+![Flow Configuration](/illustrations/flow-configuration.png)
+
+**[Code maturity](concepts/maturity-gates)** defines the rules for when a version of software can have access to the flow. It's a way for teams to define policies that control data access and impact.
+
+**Traffic configuration** and **data configuration** are the two main elements of a flow. The combination of these allows "flows" to fill the role of any dev or QA environment, in addition to supporting progressive delivery on production.

website/app/docs/concepts/maturity-based-access-controls/page.mdx

@@ -0,0 +1,32 @@
+export const metadata = {
+  title: "Kardinal Docs | Maturity-Based Access Controls",
+};
+
+# Maturity-Based Access Controls
+
+Maturity-based access controls are how teams configure [flows](concepts/flows) so that every engineer can get access to the right traffic and data at the right time for effective delivery.
+
+With maturity-based access controls, you define the level of exposure to production data and traffic along with the level of isolation that a deployed version of a service has.
+
+This can be done by combining the following configuration options:
+
+### _Traffic Source_
+
+1. Staging Traffic
+2. Dev Traffic (only the dev or QA team can generate traffic)
+
+### _Traffic Access Controls_
+
+1. Redirect (the new version completely handles the traffic)
+2. Mirror (the new version gets a duplicate of the traffic, and the output is not given to end-users)
+
+### _Data Layer_
+
+1. Obfuscated Production Data
+2. Staging Data
+4. Dev (Notional) Data
+
+### _Data Isolation Modes_
+
+1. Read/Write (full access to the database)
+2. Shared Read, Isolated Write (full read access to the database, but writes happen in an isolated commit layer)

website/app/docs/concepts/maturity-gates/page.mdx

@@ -0,0 +1,18 @@
+export const metadata = {
+  title: "Kardinal Docs | Maturity Gates",
+};
+
+# Maturity Gates
+
+Maturity gates are a way for developers to control data and traffic access throughout their team's software development lifecycle.
+
+_A maturity gate is a definition for when a version of a service can be considered stable or secure enough to get exposed to more production-like data and traffic_, and can pass to the next [flow](concepts/flows) (from QA to staging, for example).
+
+Some examples of maturity gate definitions, paired with the flows they may have:
+
+- No pull request (early development version) → [Isolated Dev Flow](use-cases/isolated-dev-sandbox-flows)
+- Pull request, unmerged → Preview Flow
+- Merged, CI passes → QA Flow
+- Passed Manual Review from the QA team → Staging Flow
+
+Maturity gates are highly configurable, so you can design any qualifications necessary to define your own maturity gates and the flows they correspond to.