Merge branch 'current' into manifest-v17

website/docs/docs/build/groups.md

@@ -19,7 +19,7 @@ This functionality is new in v1.5.
 
 ## About groups 
 
-A group is a collection of nodes within a dbt DAG. Groups are named, and every group has an `owner`. They enable intentional collaboration within and across teams by restricting [access to private](/reference/resource-properties/access) models.
+A group is a collection of nodes within a dbt DAG. Groups are named, and every group has an `owner`. They enable intentional collaboration within and across teams by restricting [access to private](/reference/resource-configs/access) models.
 
 Group members may include models, tests, seeds, snapshots, analyses, and metrics. (Not included: sources and exposures.) Each node may belong to only one group.
 
@@ -94,7 +94,7 @@ select ...
 
 ### Referencing a model in a group
 
-By default, all models within a group have the `protected` [access modifier](/reference/resource-properties/access). This means they can be referenced by downstream resources in _any_ group in the same project, using the [`ref`](/reference/dbt-jinja-functions/ref) function. If a grouped model's `access` property is set to `private`, only resources within its group can reference it. 
+By default, all models within a group have the `protected` [access modifier](/reference/resource-configs/access). This means they can be referenced by downstream resources in _any_ group in the same project, using the [`ref`](/reference/dbt-jinja-functions/ref) function. If a grouped model's `access` property is set to `private`, only resources within its group can reference it. 
 
 <File name='models/schema.yml'>
 

website/docs/docs/build/semantic-models.md

@@ -29,6 +29,7 @@ Semantic models have 6 components and this page explains the definitions with so
 | [Primary Entity](#primary-entity) | If a primary entity exists, this component is Optional. If the semantic model has no primary entity, then this property is required. | Optional |
 | [Dimensions](#dimensions) | Different ways to group or slice data for a metric, they can be `time` or `categorical` | Required |
 | [Measures](#measures) | Aggregations applied to columns in your data model. They can be the final metric or used as building blocks for more complex metrics | Optional |
+| Label | The display name for your semantic model `node`, `dimension`, `entity`, and/or `measures` | Optional |
 
 ## Semantic models components
 
@@ -231,8 +232,7 @@ For semantic models with a measure, you must have a [primary time group](/docs/b
 | `agg` | dbt supports the following aggregations: `sum`, `max`, `min`, `count_distinct`, and `sum_boolean`. | Required |
 | `expr` | You can either reference an existing column in the table or use a SQL expression to create or derive a new one. | Optional |
 | `non_additive_dimension` | Non-additive dimensions can be specified for measures that cannot be aggregated over certain dimensions, such as bank account balances, to avoid producing incorrect results. | Optional |
-| `create_metric`* | You can create a metric directly from a measure with create_metric: True and specify its display name with create_metric_display_name. | Optional |
-_*Coming soon_
+| `create_metric` | You can create a metric directly from a measure with `create_metric: True` and specify its display name with create_metric_display_name. Default is false. | Optional |
 
 
 import SetUpPages from '/snippets/_metrics-dependencies.md';

website/docs/docs/cloud/about-cloud/about-cloud-ide.md

@@ -25,7 +25,7 @@ With the Cloud IDE, you can:
 
 For more information, read the complete [Cloud IDE guide](/docs/cloud/dbt-cloud-ide/develop-in-the-cloud).
 
-## Relatd docs
+## Related docs
 
 - [IDE user interface](/docs/cloud/dbt-cloud-ide/ide-user-interface)
 - [Tips and tricks](/docs/cloud/dbt-cloud-ide/dbt-cloud-tips)

website/docs/docs/collaborate/govern/model-access.md

@@ -25,7 +25,7 @@ The two concepts will be closely related, as we develop multi-project collaborat
 
 ## Related documentation
 * [`groups`](/docs/build/groups)
-* [`access`](/reference/resource-properties/access)
+* [`access`](/reference/resource-configs/access)
 
 ## Groups
 

website/docs/docs/dbt-versions/release-notes/03-Oct-2023/custom-branch-fix-rn.md

@@ -0,0 +1,14 @@
+---
+title: "Fix: Default behavior for CI job runs without a custom branch"
+description: "October 2023: CI job runs now default to the main branch of the Git repository when a custom branch isn't set"
+sidebar_label: "Fix: Default behavior for CI job runs without a custom branch"
+tags: [Oct-2023, CI]
+date: 2023-10-06
+sidebar_position: 08
+---
+
+If you don't set a [custom branch](/docs/dbt-cloud-environments#custom-branch-behavior) for your dbt Cloud environment, it now defaults to the default branch of your Git repository (for example, `main`). Previously, [CI jobs](/docs/deploy/ci-jobs) would run for pull requests (PRs) that were opened against _any branch_ or updated with new commits if the **Custom Branch** option wasn't set. 
+
+## Azure DevOps 
+
+Your Git pull requests (PRs) might not trigger against your default branch if you're using Azure DevOps and the default branch isn't `main` or `master`. To resolve this, [set up a custom branch](/faqs/Environments/custom-branch-settings) with the branch you want to target.  

website/docs/docs/deploy/deployment-overview.md

@@ -58,6 +58,12 @@ Learn how to use dbt Cloud's features to help your team ship timely and quality
     link="/docs/deploy/run-visibility"
     icon="dbt-bit"/>
 
+<Card
+    title="Retry jobs"
+    body="Rerun your errored jobs from start or the failure point."
+    link="/docs/deploy/retry-jobs"
+    icon="dbt-bit"/>
+
 <Card
     title="Job notifications"
     body="Receive email or Slack channel notifications when a job run succeeds, fails, or is canceled so you can respond quickly and begin remediation if necessary."

website/docs/docs/deploy/monitor-jobs.md

@@ -10,6 +10,7 @@ Monitor your dbt Cloud jobs to help identify improvement and set up alerts to pr
 This portion of our documentation will go over dbt Cloud's various capabilities that help you monitor your jobs and set up alerts to ensure seamless orchestration, including:
 
 - [Run visibility](/docs/deploy/run-visibility) — View your run history to help identify where improvements can be made to scheduled jobs.
+- [Retry jobs](/docs/deploy/retry-jobs) — Rerun your errored jobs from start or the failure point.
 - [Job notifications](/docs/deploy/job-notifications) — Receive email or slack notifications when a job run succeeds, fails, or is canceled.
 - [Webhooks](/docs/deploy/webhooks) — Use webhooks to send events about your dbt jobs' statuses to other systems.
 - [Leverage artifacts](/docs/deploy/artifacts) — dbt Cloud generates and saves artifacts for your project, which it uses to power features like creating docs for your project and reporting freshness of your sources.

website/docs/docs/deploy/retry-jobs.md

@@ -4,13 +4,13 @@ sidebar_label: "Retry jobs"
 description: "Rerun your errored jobs from start or the failure point."
 ---
 
-If your dbt job run completed with a status of `result:error` , you can rerun it from start or from the point of failure in dbt Cloud.
+If your dbt job run completed with a status of **Error**, you can rerun it from start or from the point of failure in dbt Cloud.
 
 ## Prerequisites
 
 - You have a [dbt Cloud account](https://www.getdbt.com/signup).
 - You must be using [dbt version](/docs/dbt-versions/upgrade-core-in-cloud) 1.6 or newer.
-- The most recent run of the job hasn't completed successfully. The latest status of the run is `error`.
+- The most recent run of the job hasn't completed successfully. The latest status of the run is **Error**.
     - The job command that failed in the run must be one that supports the [retry command](/reference/commands/retry).
 
 ## Rerun an errored job
@@ -26,7 +26,7 @@ If your dbt job run completed with a status of `result:error` , you can rerun it
 <Lightbox src="/img/docs/deploy/native-retry.gif" width="70%" title="Example of the Rerun options in dbt Cloud"/>
 
 ## Related content
-
+- [Retry a failed run for a job](/dbt-cloud/api-v2#/operations/Retry%20a%20failed%20run%20for%20a%20job) API endpoint
 - [Run visibility](/docs/deploy/run-visibility)
 - [Jobs](/docs/deploy/jobs)
 - [Job commands](/docs/deploy/job-commands)

website/docs/guides/migration/versions/00-upgrading-to-v1.7.md

@@ -8,17 +8,45 @@ description: New features and changes in dbt Core v1.7
 - [Changelog](https://github.com/dbt-labs/dbt-core/blob/8aaed0e29f9560bc53d9d3e88325a9597318e375/CHANGELOG.md)
 - [CLI Installation guide](/docs/core/installation)
 - [Cloud upgrade guide](/docs/dbt-versions/upgrade-core-in-cloud)
-- [Release schedule](https://github.com/dbt-labs/dbt-core/issues/7481)
+- [Release schedule](https://github.com/dbt-labs/dbt-core/issues/8260)
 
 ## What to know before upgrading
 
 dbt Labs is committed to providing backward compatibility for all versions 1.x, with the exception of any changes explicitly mentioned below. If you encounter an error upon upgrading, please let us know by [opening an issue](https://github.com/dbt-labs/dbt-core/issues/new).
 
-### Behavior changes
+## New and changed features and functionality
 
-**COMING SOON**
+- [`dbt docs generate`](/reference/commands/cmd-docs) now supports `--select` to generate documentation for a subset of your project. Currently available for Snowflake and Postgres only, but other adapters are coming soon. 
+- [Source freshness](/docs/deploy/source-freshness) can now be generated from warehouse metadata tables, currently snowflake only, but other adapters that have metadata tables are coming soon. If you configure source freshness without a `loaded_at_field`, dbt will try to determine freshness from warehouse metadata tables.
+- The nodes dictionary in the `catalog.json` can now be "partial" if `dbt docs generate` is run with a selector.
+
+### MetricFlow enhancements
+
+- Automatically create metrics on measures with `create_metric: true`.
+- Optional [`label`](/docs/build/semantic-models) in semantic_models, measures, dimensions and entities.
+- New configurations for semantic models - [enable/disable](/reference/resource-configs/enabled), [group](/reference/resource-configs/group), and [meta](/reference/resource-configs/meta).
+- Support `fill_nulls_with` and `join_to_timespine` for metric nodes.
+- `saved_queries` extends governance beyond the semantic objects to their consumption.
+
+### For consumers of dbt artifacts (metadata)
+
+- The [manifest](/reference/artifacts/manifest-json) schema version has been updated to v11.
+- The [run_results](/reference/artifacts/run-results-json) schema version has been updated to v5.
+- Added [node attributes](/reference/artifacts/run-results-json) related to compilation (`compiled`, `compiled_code`, `relation_name`).
 
-### Quick hits
 
-**COMING SOON**
+### Model governance
+
+dbt Core v1.5 introduced model governance which we're continuing to refine.  v1.7 includes these additional features and functionality:
+
+- **[Breaking change detection](/reference/resource-properties/versions#detecting-breaking-changes) for models with contracts enforced:** When dbt detects a breaking change to a model with an enforced contract during state comparison, it will now raise an error for versioned models and a warning for models that are not versioned.
+- **[Set `access` as a config](/reference/resource-configs/access):** You can now set a model's `access` within config blocks in the model's file or in the `dbt_project.yml` for an entire subfolder at once.
+- **[Type aliasing for model contracts](/reference/resource-configs/contract):** dbt will use each adapter's built-in type aliasing for user-provided data types—meaning you can now write `string` always, and dbt will translate to `text` on Postgres/Redshift. This is "on" by default, but you can opt-out.
+- **[Raise warning for numeric types](/reference/resource-configs/contract):** Because of issues when putting `numeric` in model contracts without considering that default values such as `numeric(38,0)` might round decimals accordingly. dbt will now warn you if it finds a numeric type without specified precision/scale.
+
+### Quick hits
 
+With these quick hits, you can now:
+- Configure a `delimiter` for a seed file.
+- Use packages with the same git repo and unique subdirectory.
+- Moved the `date_spine` macro from dbt-utils to dbt-core.

website/docs/guides/orchestration/airflow-and-dbt-cloud/1-airflow-and-dbt-cloud.md

@@ -19,7 +19,7 @@ There are [so many great examples](https://gitlab.com/gitlab-data/analytics/-/bl
 
 ### Airflow + dbt Cloud API w/Custom Scripts
 
-This has served as a bridge until the fabled Astronomer + dbt Labs-built dbt Cloud provider became generally available [here](https://registry.astronomer.io/providers/dbt-cloud?type=Sensors&utm_campaign=Monthly%20Product%20Updates&utm_medium=email&_hsmi=208603877&utm_content=208603877&utm_source=hs_email).
+This has served as a bridge until the fabled Astronomer + dbt Labs-built dbt Cloud provider became generally available [here](https://registry.astronomer.io/providers/dbt%20Cloud/versions/latest).
 
 There are many different permutations of this over time:
 

website/docs/reference/commands/retry.md

@@ -4,14 +4,6 @@ sidebar_label: "retry"
 id: "retry"
 ---
 
-:::info Support in dbt Cloud
-
-`dbt retry` is supported in the dbt Cloud IDE.
-
-Native support for restarting scheduled runs from point of failure is currently in development & coming soon.
-
-:::
-
 `dbt retry` re-executes the last `dbt` command from the node point of failure. If the previously executed `dbt` command was successful, `retry` will finish as `no operation`. 
 
 Retry works with the following commands:

website/docs/reference/model-properties.md

@@ -18,7 +18,7 @@ models:
       show: true | false
     [latest_version](/reference/resource-properties/latest_version): <version_identifier>
     [deprecation_date](/reference/resource-properties/deprecation_date): <YAML_DateTime>
-    [access](/reference/resource-properties/access): private | protected | public
+    [access](/reference/resource-configs/access): private | protected | public
     [config](/reference/resource-properties/config):
       [<model_config>](/reference/model-configs): <config_value>
     [constraints](/reference/resource-properties/constraints):
@@ -46,7 +46,7 @@ models:
         [description](/reference/resource-properties/description): <markdown_string>
         [docs](/reference/resource-configs/docs):
           show: true | false
-        [access](/reference/resource-properties/access): private | protected | public
+        [access](/reference/resource-configs/access): private | protected | public
         [constraints](/reference/resource-properties/constraints):
           - <constraint>
         [config](/reference/resource-properties/config):

website/docs/reference/node-selection/methods.md

@@ -321,7 +321,7 @@ Supported in v1.5 or newer.
 
 <VersionBlock firstVersion="1.5">
 
-The `access` method selects models based on their [access](/reference/resource-properties/access) property.
+The `access` method selects models based on their [access](/reference/resource-configs/access) property.
 
 ```bash
 dbt list --select access:public       # list all public models

website/docs/reference/resource-configs/access.md

@@ -0,0 +1,97 @@
+---
+resource_types: [models]
+datatype: access
+---
+
+<File name='models/<schema>.yml'>
+
+```yml
+version: 2
+
+models:
+  - name: model_name
+    access: private | protected | public
+```
+
+</File>
+
+<VersionBlock lastVersion="1.6">
+
+Access modifiers may be applied to models one-by-one in YAML properties. In v1.5 and v1.6, you are unable to configure `access` for multiple models at once. Upgrade to v1.7 for additional configuration options. A group or subfolder contains models with varying access levels, so when you designate a model with `access: public`, make sure you intend for this behavior.
+
+</VersionBlock>
+
+<VersionBlock firstVersion="1.7">
+
+You can apply access modifiers in config files, including `the dbt_project.yml`, or to models one-by-one in YAML properties. Applying access configs to a subfolder modifies the default for all models in that subfolder, so make sure you intend for this behavior. When setting individual model access, a group or subfolder might contain a variety of access levels, so when you designate a model with `access: public` make sure you intend for this behavior.
+
+There are multiple approaches to configuring access:
+
+In the model configs of `dbt_project.yml``: 
+
+```yaml
+models:
+  - name: my_public_model
+    access: public # Older method, still supported
+    
+```
+Or (but not both)
+
+```yaml
+models:
+  - name: my_public_model
+    config:
+      access: public # newly supported in v1.7
+    
+```
+
+In a subfolder: 
+```yaml
+models:
+  my_project_name:
+    subfolder_name:
+      +group: <my_group>
+      +access: private  # sets default for all models in this subfolder
+```
+
+In the model.sql file:
+
+```sql
+-- models/my_public_model.sql
+
+{{ config(access = "public") }}
+
+select ...
+```
+
+</VersionBlock>
+
+## Definition
+The access level of the model you are declaring properties for.
+
+Some models (not all) are designed to be referenced through the [ref](/reference/dbt-jinja-functions/ref) function across [groups](/docs/build/groups).
+
+| Access    | Referenceable by              |
+|-----------|-------------------------------|
+| private   | same group                    |
+| protected | same project/package          |
+| public    | any group, package or project |
+
+If you try to reference a model outside of its supported access, you will see an error:
+
+```shell
+dbt run -s marketing_model
+...
+dbt.exceptions.DbtReferenceError: Parsing Error
+  Node model.jaffle_shop.marketing_model attempted to reference node model.jaffle_shop.finance_model, 
+  which is not allowed because the referenced node is private to the finance group.
+```
+
+## Default
+
+By default, all models are "protected." This means that other models in the same project can reference them.
+
+## Related docs
+
+* [Model Access](/docs/collaborate/govern/model-access#groups)
+* [Group configuration](/reference/resource-configs/group)

website/docs/reference/resource-configs/contract.md

@@ -25,9 +25,9 @@ This is to ensure that the people querying your model downstream—both inside a
 
 The `data_type` defined in your YAML file must match a data type your data platform recognizes. dbt does not do any type aliasing itself. If your data platform recognizes both `int` and `integer` as corresponding to the same type, then they will return a match.
 
-When dbt is comparing data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. If you need a more-precise assertion, it's always possible to accomplish by [writing or using a custom test](/guides/best-practices/writing-custom-generic-tests).
+When dbt compares data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. You can accomplish a more-precise assertion by [writing or using a custom test](/guides/best-practices/writing-custom-generic-tests).
 
-That said, on certain data platforms, you will need to specify a varchar size or numeric scale if you do not want it to revert to the default. This is most relevant for the `numeric` type on Snowflake, which defaults to a precision of 38 and a scale of 0 (zero digits after the decimal, such as rounded to an integer). To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`.
+Note that you need to specify a varchar size or numeric scale, otherwise dbt relies on default values. For example, if a `numeric` type defaults to a precision of 38 and a scale of 0, then the numeric column stores 0 digits to the right of the decimal (it only stores whole numbers), which might cause it to fail contract enforcement. To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`. dbt Core 1.7 and higher provides a warning if you don't specify precision and scale when providing a numeric data type.
 
 ## Example
 
@@ -47,6 +47,8 @@ models:
           - type: not_null
       - name: customer_name
         data_type: string
+      - name: non_integer
+        data_type: numeric(38,3)
 ```
 
 </File>