Docs: use Docsy alert shortcode for notes and warnings

Signed-off-by: Aravindhan Ayyanathan <aravindhan.a@est.tech>

Author: aravindtga

documentation/assets/scss/_nav.scss

@@ -3,7 +3,7 @@
 //
 
 .td-navbar-cover {
-    background: $primary;
+    background: #fff;
 
     @include media-breakpoint-up(md) {
         background: transparent !important;
@@ -20,12 +20,12 @@
 }
 
 .navbar-bg-onscroll {
-    background: $primary !important;
+    background: #fff !important;
     opacity: inherit;
 }
 
 .td-navbar {
-    background: $primary;
+    background: #fff;
     min-height: 4rem;
     margin: 0;
     z-index: 32;

documentation/assets/scss/_variables_project.scss

@@ -16,7 +16,7 @@ $kpt-blue: #00bbf9;
 $kpt-dark-pink: #a43e7b;
 $kpt-dark-blue: #0081ac;
 
-$primary: #fff;
+$primary: $kpt-dark-blue;
 
 $black: #000;
 $primary-300: #c53490;

documentation/content/en/book/04-using-functions/_index.md

@@ -253,8 +253,9 @@ pipeline:
     - exec: "sed -e 's/foo/bar/'"
 ```
 
-Note:
+{{% alert title="Note" color="primary" %}}
 You must render the package by allowing the executables. To do this, specify the `--allow-exec` command line flag, as shown below:
+{{% /alert %}}
 
 ```shell
 kpt fn render [PKG_DIR] --allow-exec
@@ -509,9 +510,10 @@ Package "wordpress":
 Successfully executed 5 function(s) in 2 package(s).
 ```
 
-Note:
+{{% alert title="Note" color="primary" %}}
 The `ensure-name-substring` function is applied only to the 
 resources matching the selection criteria.
+{{% /alert %}}
 
 If you have resources with particular labels or annotations that you want to use to select your resources, then you can use them. Here, for example, is a function that is only applied to the resources matching the label `foo: bar`:
 
@@ -672,8 +674,9 @@ Many functions take a `functionConfig` of the kind `ConfigMap`, since they only
 kpt fn eval wordpress -i set-namespace:latest -- namespace=mywordpress
 ```
 
-Note:
+{{% alert title="Note" color="primary" %}}
 The arguments must come after the separator `--`.
+{{% /alert %}}
 
 ### Specifying `selectors`
 
@@ -747,8 +750,9 @@ The `kubeconform` function can, for example, consume a JSON schema file, as foll
 kpt fn eval -i kubeconform:latest --mount type=bind,src="/path/to/schema-dir",dst=/schema-dir --as-current-user wordpress -- schema_location=file:///schema-dir
 ```
 
-Note:
+{{% alert title="Note" color="primary" %}}
 The `--as-current-user` flag may be required to run the function as your uid, instead of the default `nobody`, to access the host filesystem.
+{{% /alert %}}
 
 All the volumes are mounted as _readonly_ by default. To mount volumes in _read-write_ mode, specify `rw=true`, as follows:
 

documentation/content/en/book/06-deploying-packages/_index.md

@@ -121,9 +121,9 @@ resources in `wordpress` package are in the `default` namespace, so it chooses
 and namespace of the `ResourceGroup` resource. Refer to the
 [init command reference]({{% relref "/reference/cli/live/init" %}}) for usage.
 
-{{< warning type=warning >}}
+{{% alert title="Warning" color="warning" %}}
 Once a package is applied to the cluster, do not change the `ResourceGroup` CR. Doing so corrupts the association between the package and the inventory in the cluster, possibly leading to unpredictable and destructive operations.
-{{< /warning >}}
+{{% /alert %}}
 
 ## Applying a Package
 
@@ -135,9 +135,9 @@ Let's create that first:
 ```shell
 kubectl create secret generic mysql-pass --from-literal=password=YOUR_PASSWORD
 ```
-{{< warning type=info >}}
+{{% alert title="Note" color="primary" %}}
 You can also declare the `Secret` resource, but make sure it is not committed to Git as part of the package.
-{{< /warning >}}
+{{% /alert %}}
 
 Then deploy the package and wait for the resources to be reconciled:
 
@@ -179,10 +179,10 @@ running `kpt live apply`:
 kpt live install-resource-group
 ```
 
-{{< warning type=info >}}
+{{% alert title="Note" color="primary" %}}
 Installing this CRD requires sufficient ClusterRole permission, so you may
 need to ask your cluster admin to install it for you.
-{{< /warning >}}
+{{% /alert %}}
 
 ### Server-side vs Client-side apply
 

documentation/content/en/guides/3-way-merge.md

@@ -103,7 +103,9 @@ Replaces your entire local package with upstream, discarding all local changes.
 
 **When to use**: Only when you intentionally want to discard all customizations
 
-**Warning**: This strategy will **lose all your local modifications**. Use with caution.
+{{% alert title="Warning" color="warning" %}}
+This strategy will **lose all your local modifications**. Use with caution.
+{{% /alert %}}
 
 For complete strategy details and examples, see the [update command reference]({{% relref "/reference/cli/pkg/update" %}}).
 

documentation/content/en/guides/namespace-provisioning-cli.md

@@ -211,10 +211,12 @@ Package "tenant":
 Successfully executed 1 function(s) in 1 package(s).
 ```
 
-Note: if you are curious about how KRM functions are implemented. Take a look
+{{% alert title="Note" color="primary" %}}
+If you are curious about how KRM functions are implemented, take a look
 at [set-namespace code](https://github.com/kptdev/krm-functions-catalog/blob/main/functions/go/set-namespace/transformer/namespace.go)
 to get a feel for the implementation. You can also check out [Chapter 5: Developing Functions](/book/05-developing-functions/)
 of the kpt book.
+{{% /alert %}}
 
 ### Permissions
 

documentation/content/en/guides/tenant-onboarding.md

@@ -1,9 +1,9 @@
 # Tenant onboarding
 
-{{< warning type=warning >}}
+{{% alert title="Warning" color="warning" %}}
 This guide is a work in progress and may not fully reflect the
 current state of kpt. It is due for a rewrite.
-{{< /warning >}}
+{{% /alert %}}
 
 We have seen that in large organizations using kubernetes, there is a platform
 team (or infrastructure team) that is responsible for managing the kubernetes
@@ -14,8 +14,10 @@ learn - how you can use kpt to address the tenant use-case. Though this guide
 focuses on the tenant use-case, the pattern for package workflow discussed here
 can be applied to other use cases as well.
 
-**Note:** This guide is inspired by the [kube-common-setup](https://github.com/nghnam/kube-common-setup)
+{{% alert title="Note" color="primary" %}}
+This guide is inspired by the [kube-common-setup](https://github.com/nghnam/kube-common-setup)
 helm chart.
+{{% /alert %}}
 
 ## Terminology
 

documentation/content/en/installation/migration.md

@@ -256,8 +256,10 @@ git diff
    function definitions will be declared in `pipeline` section of Kptfile.
    Reference to function config is added via [configPath] option.
 
-Note: This function modifies only the local package files and doesn’t make any
+{{% alert title="Note" color="primary" %}}
+This function modifies only the local package files and doesn’t make any
 changes to the resources in the live cluster.
+{{% /alert %}}
 
 #### Manual portion of migration
 

documentation/content/en/reference/cli/alpha/live/plan/_index.md

@@ -10,9 +10,9 @@ description: >
     Output a plan for the changes that will happen when applying a package.
 -->
 
-{{< warning type=warning >}}
+{{% alert title="Warning" color="warning" %}}
 This feature is still in alpha, so the output format is subject to change.
-{{< /warning >}}
+{{% /alert %}}
 
 `plan` does a dry-run of applying a package to the cluster. It outputs the results
 in combination with a diff for every resource that will be updated, which gives an