Merge branch 'current' into add-sm-ci-img

README.md

@@ -62,18 +62,3 @@ You can click a link available in a Vercel bot PR comment to see and review your
 
 Advisory:
 - If you run into an `fatal error: 'vips/vips8' file not found` error when you run `npm install`, you may need to run `brew install vips`. Warning: this one will take a while -- go ahead and grab some coffee!
-
-## Running the Cypress tests locally
-
-Method 1: Utilizing the Cypress GUI
-1. `cd` into the repo: `cd docs.getdbt.com`
-2. `cd` into the `website` subdirectory: `cd website`
-3. Install the required node packages: `npm install`
-4. Run `npx cypress open` to open the Cypress GUI, and choose `E2E Testing` as the Testing Type, before finally selecting your browser and clicking `Start E2E testing in {broswer}`
-5. Click on a test and watch it run!
-
-Method 2: Running the Cypress E2E tests headlessly
-1. `cd` into the repo: `cd docs.getdbt.com`
-2. `cd` into the `website` subdirectory: `cd website`
-3. Install the required node packages: `npm install`
-4. Run `npx cypress run`

contributing/single-sourcing-content.md

@@ -90,7 +90,7 @@ This component can be added directly to a markdown file in a similar way as othe
 Both properties can be used together to set a range where the content should show. In the example below, this content will only show if the selected version is between **0.21** and **1.0**:
 
 ```markdown
-<VersionBlock lastVersion="1.6">
+<VersionBlock lastVersion="1.9">
 
 	Versioned content here
 

website/blog/2022-07-13-star-sql-love-letter.md

@@ -44,7 +44,7 @@ So what does this mean for the example from above? Instead of writing out all 55
 
 ```sql
 select
-	{{ dbt_utils.star(from=ref('table_a'), except=['column_56'] }}
+	{{ dbt_utils.star(from=ref('table_a'), except=['column_56']) }}
 from {{ ref('table_a') }}
 ```
 

website/dbt-versions.js

@@ -15,7 +15,7 @@
  */
 exports.versions = [
   {
-    version: "1.9.1",
+    version: "1.10",
     customDisplay: "Cloud (Versionless)",
   },
   {
@@ -28,11 +28,7 @@ exports.versions = [
   },
   {
     version: "1.7",
-    EOLDate: "2024-10-30",
-  },
-  {
-    version: "1.6",
-    EOLDate: "2024-07-31",
+    EOLDate: "2024-11-01",
   },
 ];
 
@@ -66,134 +62,6 @@ exports.versionedPages = [
     page: "reference/global-configs/indirect-selection",
     firstVersion: "1.8",
   },
-  {
-    page: "reference/resource-configs/store_failures_as",
-    firstVersion: "1.7",
-  },
-  {
-    page: "docs/build/build-metrics-intro",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/sl-getting-started",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/about-metricflow",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/join-logic",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/validation",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/semantic-models",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/group-by",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/entities",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/metrics-overview",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/cumulative",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/derived",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/measure-proxy",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/ratio",
-    firstVersion: "1.6",
-  },
-  {
-    page: "reference/commands/clone",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/collaborate/govern/project-dependencies",
-    firstVersion: "1.6",
-  },
-  {
-    page: "reference/dbt-jinja-functions/thread_id",
-    firstVersion: "1.6",
-  },
-  {
-    page: "reference/resource-properties/deprecation_date",
-    firstVersion: "1.6",
-  },
-  {
-    page: "reference/commands/retry",
-    firstVersion: "1.6",
-  },
-  {
-    page: "docs/build/groups",
-    firstVersion: "1.5",
-  },
-  {
-    page: "docs/collaborate/govern/model-contracts",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/commands/show",
-    firstVersion: "1.5",
-  },
-  {
-    page: "docs/collaborate/govern/model-access",
-    firstVersion: "1.5",
-  },
-  {
-    page: "docs/collaborate/govern/model-versions",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/programmatic-invocations",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/resource-configs/contract",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/resource-configs/group",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/resource-properties/access",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/resource-properties/constraints",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/resource-properties/latest_version",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/resource-properties/versions",
-    firstVersion: "1.5",
-  },
-  {
-    page: "reference/resource-configs/on_configuration_change",
-    firstVersion: "1.6",
-  },
 ];
 
 /**
@@ -206,12 +74,5 @@ exports.versionedPages = [
  * @property {string} firstVersion The first version the category is visible in the sidebar
  */
 exports.versionedCategories = [
-  {
-    category: "Model governance",
-    firstVersion: "1.5",
-  },
-  {
-    category: "Build your metrics",
-    firstVersion: "1.6",
-  },
+
 ];

website/docs/best-practices/how-we-structure/4-marts.md

@@ -26,7 +26,8 @@ models/marts
 
 ✅ **Group by department or area of concern.** If you have fewer than 10 or so marts you may not have much need for subfolders, so as with the intermediate layer, don’t over-optimize too early. If you do find yourself needing to insert more structure and grouping though, use useful business concepts here. In our marts layer, we’re no longer worried about source-conformed data, so grouping by departments (marketing, finance, etc.) is the most common structure at this stage.
 
-✅ **Name by entity.** Use plain English to name the file based on the concept that forms the grain of the mart `customers`, `orders`. Note that for pure marts, there should not be a time dimension (`orders_per_day`) here, that is typically best captured via metrics.
+✅ **Name by entity.** Use plain English to name the file based on the concept that forms the grain of the mart’s `customers`, `orders`. Marts that don't include any time-based rollups (pure marts) should not have a time dimension (`orders_per_day`) here, typically best captured via metrics.
+
 
 ❌ **Build the same concept differently for different teams.** `finance_orders` and `marketing_orders` is typically considered an anti-pattern. There are, as always, exceptions — a common pattern we see is that, finance may have specific needs, for example reporting revenue to the government in a way that diverges from how the company as a whole measures revenue day-to-day. Just make sure that these are clearly designed and understandable as _separate_ concepts, not departmental views on the same concept: `tax_revenue` and `revenue` not `finance_revenue` and `marketing_revenue`.