[pull] main from KusionStack:main

.github/workflows/build.yml

@@ -1,8 +1,14 @@
 name: build
-on: ["push", "pull_request"]
+on:
+  pull_request:
+    branches:
+    - main
+  push:
+    branches:
+    - main
 jobs:
   build:
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-latest
     steps:
       - name: Git checkout
         uses: actions/checkout@v2

.github/workflows/deploy.yml

@@ -11,7 +11,7 @@ on:
 jobs:
   deploy:
     if: (github.event_name == 'push') || github.event.pull_request.merged == true
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-latest
     steps:
       - name: Git checkout
         uses: actions/checkout@v2

.github/workflows/install.yml

@@ -0,0 +1,65 @@
+# todo: Should check the installation is correct or not! Do it in the kusion repo.
+name: installation check
+on: 
+  push:
+    branches:
+      - main
+    paths:
+      - 'static/scripts/**'
+  pull_request:
+    branches: 
+      - 'main'
+    paths:
+      - 'static/scripts/**'
+jobs:
+  check-scripts-on-macos:
+    runs-on: macos-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: check install script
+        run: static/scripts/install.sh
+      - name: check uninstall script
+        run: static/scripts/uninstall.sh
+  check-brew-on-macos:
+    runs-on: macos-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: brew install kusion
+        run: brew install KusionStack/tap/kusion
+  check-scripts-on-linux:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: check install script
+        run: static/scripts/install.sh
+      - name: check uninstall script
+        run: static/scripts/uninstall.sh
+  check-brew-on-linux:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: Homebrew/actions/setup-homebrew@master
+      - name: brew install kusion
+        run: brew install KusionStack/tap/kusion
+        shell: bash -ieo pipefail {0}
+#  check-powershell-on-windows:
+#    runs-on: windows-latest
+#    steps:
+#      - uses: actions/checkout@v3
+#      - name: check install script
+#        run: static/scripts/install.ps1
+#        shell: powershell
+#      - name: check kusion run
+#        run: C:\kusion\kusion.exe compile -w static/stack -o stdout
+#        shell: powershell
+#  check-scoop-on-windows:
+#    runs-on: windows-latest
+#    steps:
+#      - uses: actions/checkout@v3
+#      - name: scoop install kusion
+#        run: |
+#          iex "& {$(irm get.scoop.sh)} -RunAsAdmin"
+#          scoop bucket add KusionStack https://github.com/KusionStack/scoop-bucket.git
+#          scoop install KusionStack/kusion
+#          # kusion compile -w static/stack -o stdout
+#        shell: powershell

.gitignore

@@ -21,4 +21,5 @@ yarn-debug.log*
 yarn-error.log*
 
 .vscode/
-.idea/
+.idea/
+.obsidian/

CODE_OF_CONDUCT.md

@@ -0,0 +1,3 @@
+# KusionStack Community Code of Conduct
+
+KusionStack follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).

README.md

@@ -9,24 +9,75 @@ Source for kusionstack.io site <https://kusionstack.io>.
 
 Powered by [Docusaurus 2](https://docusaurus.io/).
 
-## Build local
+## Write documentation for each sub product
 
-```
+Write documentation for sub products in the `./docs/[subProductName]` directory.
+
+## Build locally
+
+```shell
+$ rm -rf .docusaurus
 $ npm install
 $ npm run start
 ```
 
-Open http://localhost:3000 in browser.
+Open http://localhost:3000 in the browser.
 
-## Build local with i18n
+## Build locally with i18n
 
-```
-$ npm build
+```shell
+$ npm run build
 $ npx http-server ./build
 ```
 
-Open http://localhost:8080 in browser.
+Open http://localhost:8080 in the browser.
+
+## Tagging a new version for each sub product
+
+1. First, make sure the current docs version (the `./docs/[subProductName]` directory) is ready to be frozen.
+2. Enter the specified sub product name and a new version number:
+
+```bash
+npm run docusaurus docs:version:[subProductName] [vMAJOR.MINOR]
+
+# If the sub product has an international document and needs to execute the command again, 
+# it will generate the i18n directory corresponding to that version.
+npm run write-translations -- --locale [localeName] --override
+```
+
+Example:
+
+```bash
+npm run docusaurus docs:version:docs v0.12
+npm run docusaurus docs:version:kuperator v0.2
+npm run docusaurus docs:version:ctrlmesh v0.3
+npm run docusaurus docs:version:karpor v0.4
+
+# If the sub product has an international document and needs to execute the command again, 
+# it will generate the i18n directory corresponding to that version.
+npm run write-translations -- --locale zh --override
+```
+
+Optional sub product names:
+
+-   `docs` (alias for kusion)
+-   `kuperator`
+-   `ctrlmesh`
+-   `karpor`
+
+Format of version number: `[vMAJOR.MINOR]`, e.g. `v0.3`, `v0.13`.
+
+When tagging a new version of sub product, the document versioning mechanism will:
+
+-   Copy the full `docs/[subProductName]` folder contents into a new `[subProductName]_versioned_docs/version-[versionName]/` folder.
+-   Create a versioned sidebars file based from your current [sidebar](docs-introduction.mdx#sidebar) configuration (if it exists) - saved as `[subProductName]_versioned_sidebars/version-[versionName]-sidebars.json`.
+-   Append the new version number to `[subProductName]_versions.json`.
+
+More see:
+
+-   [Versioning](https://docusaurus.io/docs/versioning)
+-   [Docs Multi-instance](https://docusaurus.io/zh-CN/docs/2.x/docs-multi-instance#tagging-new-versions)
 
 ## Notice
 
-This website is built under Docusaurus version 2.0.0-beta.17. There may be unknown errors when compiling on other versions.
+This website is built under Docusaurus version 2.4.1. There may be unknown errors when compiling on other versions.

blog/2022-09-15-declarative-config-overview/_index.md

@@ -170,11 +170,11 @@ Fig. 5: KCL core features.
 
 - **Easy-to-use**: Originated from high-level languages ​​such as Python and Golang, incorporating functional language features with low side effects.
 - **Well-designed**: Independent Spec-driven syntax, semantics, runtime and system modules design.
-- **Quick modeling**: [Schema](https://kusionstack.io/docs/reference/lang/lang/tour#schema)-centric configuration types and modular abstraction.
-- **Rich capabilities**: Configuration with type, logic and policy based on [Config](https://kusionstack.io/docs/reference/lang/lang/codelab/simple), [Schema](https://kusionstack.io/docs/reference/lang/lang/tour/#schema), [Lambda](https://kusionstack.io/docs/reference/lang/lang/tour/#function), [Rule](https://kusionstack.io/docs/reference/lang/lang/tour/#rule).
-- **Stability**: Configuration stability built on [static type system](https://kusionstack.io/docs/reference/lang/lang/tour/#type-system), [constraints](https://kusionstack.io/docs/reference/lang/lang/tour/#validation), and [rules](https://kusionstack.io/docs/reference/lang/lang/tour#rule).
-- **Scalability**: High scalability through [automatic merge mechanism](https://kusionstack.io/docs/reference/lang/lang/tour/#-operators-1) of isolated config blocks.
-- **Fast automation**: Gradient automation scheme of [CRUD APIs](https://kusionstack.io/docs/reference/lang/lang/tour/#kcl-cli-variable-override), [multilingual SDKs](https://kusionstack.io/docs/reference/lang/xlang-api/overview), [language plugin](https://github.com/KusionStack/kcl-plugin)
+- **Quick modeling**: [Schema](https://kcl-lang.io/docs/reference/lang/tour/#schema)-centric configuration types and modular abstraction.
+- **Rich capabilities**: Configuration with type, logic and policy based on [Config](https://kusionstack.io/docs/reference/lang/lang/codelab/simple), [Schema](https://kcl-lang.io/docs/reference/lang/tour/#schema), [Lambda](https://kcl-lang.io/docs/reference/lang/tour/#function), [Rule](https://kcl-lang.io/docs/reference/lang/tour/#rule).
+- **Stability**: Configuration stability built on [static type system](https://kcl-lang.io/docs/reference/lang/tour/#type-system), [constraints](https://kcl-lang.io/docs/reference/lang/tour/#validation), and [rules](https://kcl-lang.io/docs/reference/lang/tour/#rule).
+- **Scalability**: High scalability through [automatic merge mechanism](https://kcl-lang.io/docs/reference/lang/tour/#operators) of isolated config blocks.
+- **Fast automation**: Gradient automation scheme of [CRUD APIs](https://kcl-lang.io/docs/reference/lang/tour/#kcl-cli-variable-override), [multilingual SDKs](https://kusionstack.io/docs/reference/lang/xlang-api/overview), [language plugin](https://github.com/KusionStack/kcl-plugin)
 - **High performance**: High compile time and runtime performance using Rust & C and [LLVM](https://llvm.org/), and support compilation to native code and [WASM](https://webassembly.org/).
 - **API affinity**: Native support API ecological specifications such as [OpenAPI](https://github.com/KusionStack/kcl-openapi), Kubernetes CRD, Kubernetes YAML spec.
 - **Development friendly**: Friendly development experiences with rich [language tools](https://kusionstack.io/docs/reference/cli/kcl/) (Format, Lint, Test, Vet, Doc, etc.) and [IDE plugins](https://github.com/KusionStack/vscode-kcl).
@@ -185,7 +185,7 @@ Fig. 5: KCL core features.
 
 Fig. 6: KCL core design.
 
-For more language design and capabilities, see [KCL Documents](https://kusionstack.io/docs/reference/lang/lang/tour). Although KCL is not a general language, it has corresponding application scenarios. As shown in Fig. 6, developers can write **config**, **schema**, **function** and **rule** through KCL, where config is used to define data, schema is used to describe the model definition of data, rule is used to validate data, and schema and rule can also be combined to use models and constraints that fully describe data, In addition, we can also use the lambda pure function in KCL to organize data code, encapsulate common code, and call it directly when needed.
+For more language design and capabilities, see [KCL Documents](https://kcl-lang.io/docs/reference/lang/tour/). Although KCL is not a general language, it has corresponding application scenarios. As shown in Fig. 6, developers can write **config**, **schema**, **function** and **rule** through KCL, where config is used to define data, schema is used to describe the model definition of data, rule is used to validate data, and schema and rule can also be combined to use models and constraints that fully describe data, In addition, we can also use the lambda pure function in KCL to organize data code, encapsulate common code, and call it directly when needed.
 
 For use cases, KCL can perform structured K-V data validation complex configuration model definition and abstraction, strong constraint verification to avoid configuration errors, automation integration and engineering expansion. These features and use cases are described below.
 
@@ -759,7 +759,7 @@ The blog gives the landscape overview of declarative configuration technology, f
 - Kustomize: [https://kustomize.io/](https://kustomize.io/)
 - Kube-linter: [https://github.com/stackrox/kube-linter](https://github.com/stackrox/kube-linter)
 - Checkov: [https://github.com/bridgecrewio/checkov](https://github.com/bridgecrewio/checkov)
-- KCL Documents: [https://kusionstack.io/docs/reference/lang/lang/tour](https://kusionstack.io/docs/reference/lang/lang/tour)
+- KCL Documents: [https://kcl-lang.io/docs/reference/lang/tour/](https://kcl-lang.io/docs/reference/lang/tour/)
 - How Terraform Works: A Visual Intro: [https://betterprogramming.pub/how-terraform-works-a-visual-intro-6328cddbe067](https://betterprogramming.pub/how-terraform-works-a-visual-intro-6328cddbe067) 
 - How Terraform Works: Modules Illustrated: [https://awstip.com/terraform-modules-illustrate-26cbc48be83a](https://awstip.com/terraform-modules-illustrate-26cbc48be83a)
 - Helm: [https://helm.sh/](https://helm.sh/)