change docs to match dbt fusion

Author: haritamar

.pre-commit-config.yaml

@@ -44,8 +44,10 @@ repos:
         language: system
         files: ^elementary/.*\.py$
 
-  - repo: https://github.com/CoderJoshDK/precommit-mintlify-validate/
-    rev: v0.2.0
-    hooks:
-      - id: mintlify-validate
-        args: [docs]
+  # Commented this out because docs changes are often not done by developers and therefore
+  # the pre-commit doesn't routinely run on the docs.
+  # - repo: https://github.com/CoderJoshDK/precommit-mintlify-validate/
+  #   rev: v0.2.0
+  #   hooks:
+  #     - id: mintlify-validate
+  #       args: [docs]

docs/_snippets/alerts/description.mdx

@@ -4,10 +4,11 @@ It's recommended to add an explanation of what does it mean if this test fails,
 <CodeGroup>
 
 ```yml test
-tests:
+data_tests:
   - not_null:
-    meta:
-      description: "This is the test description"
+    config:
+      meta:
+        description: "This is the test description"
 ```
 
 ```yml test config block
@@ -20,7 +21,7 @@ tests:
 ```
 
 ```yml dbt_project.yml
-tests:
+data_tests:
   path:
     subfolder:
       +meta:

docs/_snippets/alerts/owner.mdx

@@ -8,15 +8,17 @@ Elementary enriches alerts with [owners for models or tests](https://docs.getdbt
 ```yml model
 models:
   - name: my_model_name
-    meta:
-      owner: "@jessica.jones"
+    config:
+      meta:
+        owner: "@jessica.jones"
 ```
 
 ```yml test
-tests:
+data_tests:
   - not_null:
-    meta:
-      owner: ["@jessica.jones", "@joe.joseph"]
+    config:
+      meta:
+        owner: ["@jessica.jones", "@joe.joseph"]
 ```
 
 ```yml test/model config block
@@ -36,7 +38,7 @@ models/sources:
       +meta:
         owner: "@jessica.jones"
 
-tests:
+data_tests:
   path:
     subfolder:
       +meta:

docs/_snippets/alerts/subscribers.mdx

@@ -8,15 +8,17 @@ If you want additional users besides the owner to be tagged on an alert, add the
 ```yml model
 models:
   - name: my_model_name
-    meta:
-      subscribers: "@jessica.jones"
+    config:
+      meta:
+        subscribers: "@jessica.jones"
 ```
 
 ```yml test
-tests:
+data_tests:
   - not_null:
-    meta:
-      subscribers: ["@jessica.jones", "@joe.joseph"]
+    config:
+      meta:
+        subscribers: ["@jessica.jones", "@joe.joseph"]
 ```
 
 ```yml test/model config block
@@ -34,7 +36,7 @@ models:
       +meta:
         subscribers: "@jessica.jones"
 
-tests:
+data_tests:
   path:
     subfolder:
       +meta:

docs/_snippets/alerts/tags.mdx

@@ -12,7 +12,7 @@ models:
 ```
 
 ```yml test
-tests:
+data_tests:
   - not_null:
     tags: ["#marketing", "#data_ops"]
 ```
@@ -30,7 +30,7 @@ models:
     subfolder:
       tags: ["#marketing", "#data_ops"]
 
-tests:
+data_tests:
   path:
     subfolder:
       tags: ["#marketing", "#data_ops"]

docs/_snippets/guides/alerts-code-configuration.mdx

@@ -76,15 +76,17 @@ the CLI or the `config.yml` file.
 ```yml model
 models:
   - name: my_model_name
-    meta:
-      channel: data_ops
+    config:
+      meta:
+        channel: data_ops
 ```
 
 ```yml test
-tests:
+data_tests:
   - not_null:
-    meta:
-      channel: data_ops
+    config:
+      meta:
+        channel: data_ops
 ```
 
 ```yml test/model config block
@@ -102,7 +104,7 @@ models:
       +meta:
         channel: data_ops
 
-tests:
+data_tests:
   path:
     subfolder:
       +meta:
@@ -126,15 +128,17 @@ Note: if you configure a suppression interval using this method, it will overrid
 ```yml model
 models:
   - name: my_model_name
-    meta:
-      alert_suppression_interval: 24
+    config:
+      meta:
+        alert_suppression_interval: 24
 ```
 
 ```yml test
-tests:
+data_tests:
   - not_null:
-    meta:
-      alert_suppression_interval: 12
+    config:
+      meta:
+        alert_suppression_interval: 12
 ```
 
 ```yml test/model config block
@@ -152,7 +156,7 @@ models:
       +meta:
         alert_suppression_interval: 24
 
-tests:
+data_tests:
   path:
     subfolder:
       +meta:
@@ -176,15 +180,17 @@ Due to their nature, grouped alerts will contain less information on each issue.
 ```yml model
 models:
   - name: my_model_name
-    meta:
-      slack_group_alerts_by: table
+    config:
+      meta:
+        slack_group_alerts_by: table
 ```
 
 ```yml test
-tests:
+data_tests:
   - not_null:
-    meta:
-      slack_group_alerts_by: table
+    config:
+      meta:
+        slack_group_alerts_by: table
 ```
 
 ```yml test/model config block
@@ -202,7 +208,7 @@ models:
       +meta:
         slack_group_alerts_by: table
 
-tests:
+data_tests:
   path:
     subfolder:
       +meta:
@@ -236,15 +242,17 @@ Supported alert fields:
 ```yml model
 models:
   - name: my_model_name
-    meta:
-      alert_fields: ["description", "owners", "tags", "subscribers"]
+    config:
+      meta:
+        alert_fields: ["description", "owners", "tags", "subscribers"]
 ```
 
 ```yml test
-tests:
+data_tests:
   - not_null:
-    meta:
-      alert_fields: ["description", "owners", "tags", "subscribers"]
+    config:
+      meta:
+        alert_fields: ["description", "owners", "tags", "subscribers"]
 ```
 
 ```yml test/model config block
@@ -262,7 +270,7 @@ models:
       +meta:
         alert_fields: ["description", "owners", "tags", "subscribers"]
 
-tests:
+data_tests:
   path:
     subfolder:
       +meta:

docs/cloud/best-practices/governance-for-observability.mdx

@@ -43,14 +43,15 @@ A data asset or test should have only one owner, but other people might want to
 ```yaml
 models:
   - name: return_on_ad_spend
-    tags:
-	    - marketing-public
-	    - marketing
-    meta:
-	    owner: :"@analytics.engineer"
-      subscribers:
-      - "@marketing.data.analyst"
-      - "@another.marketing.data.analyst"
+    config:
+      tags:
+        - marketing-public
+        - marketing
+      meta:
+        owner: :"@analytics.engineer"
+        subscribers:
+        - "@marketing.data.analyst"
+        - "@another.marketing.data.analyst"
 ```
 
 ## Business domains & Data products
@@ -108,12 +109,13 @@ Ownership and subscribers:
 ```yaml
 sources:
   - name: fivetran_salesforce_sync
-    tags:
-     - fivetran
-     - salesforce
-    meta:
-	    owner: :"@data.engineer"
-      subscribers: "@analytics.engineer"
+    config:
+      tags:
+      - fivetran
+      - salesforce
+      meta:
+        owner: :"@data.engineer"
+        subscribers: "@analytics.engineer"
 ```
 
 <Check>

docs/cloud/best-practices/triage-and-response.mdx

@@ -38,14 +38,14 @@ According to these answers, you should add configuration that will impact the al
 </Check>
 
 ```yaml
-tests:
+data_tests:
   - unique:
 		  config:
 		    error_if: ">10"
-      meta:
-        description: "More than 10 duplicate records arriving from the source, as this is a staging table"
-        owner: "@data.provider"
-        tags: "critical", "mongo-db", "raw-production-replica"
+        meta:
+          description: "More than 10 duplicate records arriving from the source, as this is a staging table"
+          owner: "@data.provider"
+          tags: "critical", "mongo-db", "raw-production-replica"
 ```
 
 ## Alert distribution
@@ -129,7 +129,7 @@ These are the questions that should be asked, and product tips on how to answer
 - Does the incident break the pipeline / create delay?
 
   - Is the failure is a model failure, or a freshness issue?
-  - Do we run `dbt build` and this failure stoped the pipeline?
+  - Do we run `dbt build` and this failure stopped the pipeline?
 
     - Check the **Model runs** section of the dashboard to see if there are skipped models, as failures in build cause the downstream models to be skipped.