Merge branch 'current' into sortable-table

website/docs/docs/build/incremental-microbatch.md

@@ -8,9 +8,7 @@ id: "incremental-microbatch"
 
 :::info Microbatch
 
-The `microbatch` strategy is available in beta for [dbt Cloud Versionless](/docs/dbt-versions/upgrade-dbt-version-in-cloud#versionless) and dbt Core v1.9. 
-
-If you use a custom microbatch macro, set a [distinct behavior flag](/reference/global-configs/behavior-changes#custom-microbatch-strategy) in your `dbt_project.yml` to enable batched execution. If you don't have a custom microbatch macro, you don't need to set this flag as dbt will handle microbatching automatically for any model using the [microbatch strategy](#how-microbatch-compares-to-other-incremental-strategies).
+The `microbatch` strategy is available in beta for [dbt Cloud Versionless](/docs/dbt-versions/upgrade-dbt-version-in-cloud#versionless) and dbt Core v1.9. We have been developing it behind a flag to prevent unintended interactions with existing custom incremental strategies. To enable this feature, [set the environment variable](/docs/build/environment-variables#setting-and-overriding-environment-variables) `DBT_EXPERIMENTAL_MICROBATCH` to `True` in your dbt Cloud environments or wherever you're running dbt Core.
 
 Read and participate in the discussion: [dbt-core#10672](https://github.com/dbt-labs/dbt-core/discussions/10672)
 

website/docs/docs/build/incremental-strategy.md

@@ -289,8 +289,6 @@ For example, a user-defined strategy named `insert_only` can be defined and used
 
 </File>
 
-If you use a custom microbatch macro, set a [`require_batched_execution_for_custom_microbatch_strategy` behavior flag](/reference/global-configs/behavior-changes#custom-microbatch-strategy) in your `dbt_project.yml` to enable batched execution of your custom strategy. 
-
 ### Custom strategies from a package
 
 To use the `merge_null_safe` custom incremental strategy from the `example` package:

website/docs/docs/cloud/about-cloud/regions-ip-addresses.md

@@ -45,7 +45,7 @@ dbt Cloud, like many cloud services, relies on underlying AWS cloud infrastructu
 
 * Dynamic IP addresses — dbt Cloud infrastructure uses Amazon Web Services (AWS). dbt Cloud offers static URLs for streamlined access, but the dynamic nature of cloud services means the underlying IP addresses change occasionally. AWS manages the IP ranges and may change them according to their operational and security needs.
 
-* Using hostnames for consistent access — To ensure uninterrupted access, we recommend that you dbt Cloud services using hostnames. Hostnames provide a consistent reference point, regardless of any changes in underlying IP addresses. We are aligning with an industry-standard practice employed by organizations such as Snowflake.
+* Using hostnames for consistent access — To ensure uninterrupted access, we recommend that you use dbt Cloud services using hostnames. Hostnames provide a consistent reference point, regardless of any changes in underlying IP addresses. We are aligning with an industry-standard practice employed by organizations such as Snowflake.
 
 * Optimizing VPN connections — You should integrate a proxy alongside VPN for users who leverage VPN connections. This strategy enables steady IP addresses for your connections, facilitating smooth traffic flow through the VPN and onward to dbt Cloud. By employing a proxy and a VPN, you can direct traffic through the VPN and then to dbt Cloud. It's crucial to set up the proxy if you need to integrate with additional services.
 

website/docs/docs/dbt-versions/release-notes.md

@@ -19,7 +19,6 @@ Release notes are grouped by month for both multi-tenant and virtual private clo
 \* The official release date for this new format of release notes is May 15th, 2024. Historical release notes for prior dates may not reflect all available features released earlier this year or their tenancy availability.
 
 ## November 2024
-- **Behavior change**: If you use a custom microbatch macro, set a [`require_batched_execution_for_custom_microbatch_strategy` behavior flag](/reference/global-configs/behavior-changes#custom-microbatch-strategy) in your `dbt_project.yml` to enable batched execution. If you don't have a custom microbatch macro, you don't need to set this flag as dbt will handle microbatching automatically for any model using the [microbatch strategy](/docs/build/incremental-microbatch#how-microbatch-compares-to-other-incremental-strategies).
 - **Fix**: This update improves [dbt Semantic Layer Tableau integration](/docs/cloud-integrations/semantic-layer/tableau) making query parsing more reliable. Some key fixes include:
   - Error messages for unsupported joins between saved queries and ALL tables.
   - Improved handling of queries when multiple tables are selected in a data source.

website/docs/docs/dbt-versions/versionless-cloud.md

@@ -51,10 +51,11 @@ The legacy dbt Semantic Layer was deprecated in the second half of 2023. We reco
 <Expandable alt_header="What are other known issues when upgrading from older dbt Core versions?" >
 
 If you are upgrading from a very old unsupported version of dbt Core, you may run into one of these edge cases after the upgrade to a newer version:
+- [v1.1] Customers on BigQuery should be aware that dbt Cloud sets a default [per-model timeout](/docs/core/connect-data-platform/bigquery-setup#job_execution_timeout_seconds) of 5 minutes. You may override this config in your connection details. Older versions of dbt (including v1.0) did not appropriately respect this timeout configuration.
 - [v1.3] Customers with non-dbt `.py` files defined within their project directories, such as `models/`. Since v1.3, dbt expects these files be valid [Python models](/docs/build/python-models). The customer needs to move these files out of their `models/` directory, or ignore them via `.dbtignore`
 - [v1.5] Customers who have `--m` in their job definitions, instead of `-m` or `--models`. This autocompletion (`--m[odels]` for `--models`) has never been officially documented or supported. It was an implicit behavior of argparse (CLI library used in dbt-core v1.0-1.4) that is not supported by `click` (the CLI library used in dbt-core since v1.5+).
 - [v1.5] Empty invalid `tests` config start raising a validation error](https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-v1.5). Replace empty `tests` config with `tests: []` or remove it altogether.
-- [v1.6] Performance optimization to `load_result` means you cannot call it on the same query result multiple times (https://github.com/dbt-labs/dbt-core/pull/7371)
+- [v1.6] Performance optimization to `load_result` means you cannot call it on the same query result multiple times. Instead, save it to a local variable once, and reuse that variable (context: [dbt-core#7371](https://github.com/dbt-labs/dbt-core/pull/7371)
 
 You should [contact dbt Cloud support](https://docs.getdbt.com/docs/dbt-support#dbt-cloud-support) to request an extension, during which you will need to make those updates.
 

website/docs/faqs/Accounts/change-users-license.md

@@ -8,12 +8,12 @@ id: change-user-license
 
 To change the license type for a user from `developer` to `read-only` or `IT` in dbt Cloud, you must be an account owner or have admin privileges. You might make this change to free up a billable seat but retain the user’s access to view the information in the dbt Cloud account.
 
-1. From dbt Cloud, click the gear icon at the top right and select **Account Settings**.
+1. From dbt Cloud, click on your account name in the left side menu and, select **Account settings**.
 
-<Lightbox src="/img/docs/dbt-cloud/Navigate To Account Settings.png" title="Navigate to account settings" />
+<Lightbox src="/img/docs/dbt-cloud/Navigate-to-account-settings.png" title="Navigate to account settings" />
 
 2. In **Account Settings**, select **Users** under **Teams**.
-3. Select the user you want to remove, and click **Edit** in the bottom of their profile.
+3. Select the user you want to remove and click **Edit** in the bottom of their profile.
 4. For the **License** option, choose **Read-only** or **IT** (from **Developer**), and click **Save**.
 
-<Lightbox src="/img/docs/dbt-cloud/change_user_to_read_only_20221023.gif" title="Change users license type" />
+<Lightbox src="/img/docs/dbt-cloud/change_user_to_read_only_20221023.gif" title="Change user's license type" />

website/docs/guides/starburst-galaxy-qs.md

@@ -203,7 +203,7 @@ To query the Jaffle Shop data with Starburst Galaxy, you need to create tables u
 3. Click **Clusters** on the left sidebar.
 4. Find your cluster in the **View clusters** table and click **Connection info**. Choose **dbt** from the **Select client** dropdown. Keep the **Connection information** modal open. You will use details from that modal in dbt Cloud.
 5. In another browser tab, log in to [dbt Cloud](/docs/cloud/about-cloud/access-regions-ip-addresses).
-6. Create a new project in dbt Cloud. From Account settings (using the gear menu in the top right corner), click **+ New Project**.
+6. Create a new project in dbt Cloud. Click on your account name in the left side menu, select **Account settings**, and click **+ New Project**.
 7. Enter a project name and click **Continue**.
 8. Choose **Starburst** as your connection and click **Next**.
 9. Enter the **Settings** for your new project:

website/docs/guides/teradata-qs.md

@@ -104,7 +104,7 @@ If you created your Teradata Vantage database instance at https://clearscape.ter
 
 ## Connect dbt Cloud to Teradata
 
-1. Create a new project in dbt Cloud. From **Account settings** (using the gear menu in the top right corner), click **New Project**. 
+1. Create a new project in dbt Cloud. Click on your account name in the left side menu, select **Account settings**, and click **+ New Project**. 
 2. Enter a project name and click **Continue**.
 3. In **Configure your development environment**, click **Add new connection**.
 4. Select **Teradata**, fill in all the required details in the **Settings** section, and test the connection.

website/docs/reference/commands/deps.md

@@ -60,25 +60,47 @@ Update your versions in packages.yml, then run dbt deps
 
 ## Predictable package installs
 
-Starting in dbt Core v1.7, dbt generates a `package-lock.yml` file in the root of your project. This contains the complete set of resolved packages based on the `packages` configuration in `dependencies.yml` or `packages.yml`. Each subsequent invocation of `dbt deps` will install from the _locked_ set of packages specified in this file. Storing the complete set of required packages (with pinned versions) in version-controlled code ensures predictable installs in production and consistency across all developers and environments. 
+Starting in dbt v1.7, dbt generates a `package-lock.yml` file in the root of your project. This file ensures consistent and predictable package installs by storing the exact versions (including commit SHAs) of all resolved packages specified in your `packages.yml` or `dependencies.yml`. This consistency is crucial for maintaining stability in development and production environments, preventing unexpected issues from new releases with potential bugs.
 
-The `package-lock.yml` file should be committed in Git initially, and then updated and committed only when you want to change versions or uninstall a package (for example  `dbt deps --upgrade` or `dbt deps --lock`).
+When you run `dbt deps`, dbt installs packages based on the locked versions in `package-lock.yml`. To update these locked versions, you must explicitly run `dbt deps --upgrade` and commit the updated `package-lock.yml` file. Storing this file in version control guarantees consistency across all environments and for all developers.
 
-The `package-lock.yml` file includes a `sha1_hash` of the `packages` config. This enables dbt to detect if the `packages` config has been updated, and to rerun dependency resolution. To only check for changes to the `packages` config and update the lock file accordingly without installing those packages, provide the `--lock` flag (that is, `dbt deps --lock`).
+### Managing `package-lock.yml`
 
-### Forcing upgrades
+The `package-lock.yml` file should be committed to Git initially and updated only when you intend to change versions or uninstall a package. For example, run `dbt deps --upgrade` to get updated package versions or `dbt deps --lock` to update the lock file based on changes to the packages config without installing the packages.
 
-It's possible to force package resolution to rerun, even if the `packages` config hasn't changed, by running `dbt deps --upgrade`. This enables you to get the latest commits from the `main` branch of an internally maintained `git` package while accepting the risk of unpredictable builds. 
+To bypass using `package-lock.yml` entirely, you can add it to your project's `.gitignore`. However, this approach sacrifices the predictability of builds. If you choose this route, we strongly recommend adding version pins for third-party packages in your `packages` config.
 
-An alternative to running `dbt deps --upgrade` in production is to "ignore" the lock file by adding `package-lock.yml` to your project's `.gitignore` file. 
+### Detecting changes in `packages` config
 
-If you pursue either approach, dbt Labs strongly recommends adding version pins for third-party packages within your `packages` config.
+The `package-lock.yml` file includes a `sha1_hash` of your packages config. If you update `packages.yml`, dbt will detect the change and rerun dependency resolution during the next `dbt deps` command. To update the lock file without installing the new packages, use the `--lock` flag:
 
-## Add specific packages
+```shell
+dbt deps --lock
+```
+
+### Forcing package updates
+
+To update all packages, even if `packages.yml` hasn’t changed, use the `--upgrade` flag:
+
+```shell
+
+dbt deps --upgrade
+
+```
+
+This is particularly useful for fetching the latest commits from the `main` branch of an internally maintained Git package. 
+
+:::warning
+Forcing package upgrades may introduce build inconsistencies unless carefully managed.
+:::
+
+### Adding specific packages
 
-The `dbt deps` command can add or update an existing package configuration — no need to remember the exact syntax for package configurations. 
+The `dbt deps` command can add or update package configurations directly, saving you from remembering exact syntax. 
 
-For Hub packages (default), which are the easiest to install:
+#### Hub packages (default)
+
+Hub packages are the default package types and the easiest to install.
 
 ```shell
 dbt deps --add-package dbt-labs/[email protected]
@@ -87,11 +109,15 @@ dbt deps --add-package dbt-labs/[email protected]
 dbt deps --add-package dbt-labs/snowplow@">=0.7.0,<0.8.0"
 ```
 
-For other package types, use the `--source` flag:
+#### Non-Hub packages
+
+Use the `--source` flag to specify the type of package to be installed:
+
 ```shell
-# add package from git
+
+# Git package
 dbt deps --add-package https://github.com/fivetran/[email protected] --source git
 
-# add package from local
+# Local package
 dbt deps --add-package /opt/dbt/redshift --source local
 ```

website/docs/reference/global-configs/behavior-changes.md

@@ -59,7 +59,6 @@ flags:
   source_freshness_run_project_hooks: False
   restrict_direct_pg_catalog_access: False
   require_yaml_configuration_for_mf_time_spines: False
-  require_batched_execution_for_custom_microbatch_strategy: False
 ```
 
 </File>
@@ -75,7 +74,6 @@ When we use dbt Cloud in the following table, we're referring to accounts that h
 | [skip_nodes_if_on_run_start_fails](#failures-in-on-run-start-hooks)                                | 2024.10          | TBD*                | 1.9.0           | TBD*              |
 | [state_modified_compare_more_unrendered_values](#source-definitions-for-state)                   | 2024.10          | TBD*                | 1.9.0           | TBD*              |
 | [require_yaml_configuration_for_mf_time_spines](#metricflow-time-spine-yaml)                  | 2024.10          | TBD*                | 1.9.0           | TBD*              |
-| [require_batched_execution_for_custom_microbatch_strategy](#custom-microbatch-strategy)                  | 2024.11         | TBD*                | 1.9.0           | TBD*              |
 
 When the dbt Cloud Maturity is "TBD," it means we have not yet determined the exact date when these flags' default values will change. Affected users will see deprecation warnings in the meantime, and they will receive emails providing advance warning ahead of the maturity date. In the meantime, if you are seeing a deprecation warning, you can either:
 - Migrate your project to support the new behavior, and then set the flag to `True` to stop seeing the warnings.
@@ -166,12 +164,3 @@ In previous versions (dbt Core 1.8 and earlier), the MetricFlow time spine confi
 When the flag is set to `True`, dbt will continue to support the SQL file configuration. When the flag is set to `False`, dbt will raise a deprecation warning if it detects a MetricFlow time spine configured in a SQL file. 
 
 The MetricFlow YAML file should have the `time_spine:` field. Refer to [MetricFlow timespine](/docs/build/metricflow-time-spine) for more details. 
-
-### Custom microbatch strategy
-The `require_batched_execution_for_custom_microbatch_strategy` flag is set to `False` by default and is only relevant if you already have a custom microbatch macro in your project.  If you don't have a custom microbatch macro, you don't need to set this flag as dbt will handle microbatching automatically for any model using the [microbatch strategy](/docs/build/incremental-microbatch#how-microbatch-compares-to-other-incremental-strategies).
-
-Set the flag is set to `True` if you have a custom microbatch macro set up in your project. When the flag is set to `True`, dbt will execute the custom microbatch strategy in batches. 
-
-If you have a custom microbatch macro and the flag is left as `False`, dbt will issue a deprecation warning.
-
-Previously, users needed to set the `DBT_EXPERIMENTAL_MICROBATCH` environment variable to `True` to prevent unintended interactions with existing custom incremental strategies. But this is no longer necessary, as setting `DBT_EXPERMINENTAL_MICROBATCH` will no longer have an effect on runtime functionality.

website/snippets/cloud-feature-parity.md

@@ -6,6 +6,7 @@ The following table outlines which dbt Cloud features are supported on the diffe
 | Continuous integration jobs   | ✅               | ✅                     | ✅                  | ✅                  |
 | dbt Cloud CLI                 | ✅               | ✅                     | ✅                  | ✅                  |
 | dbt Cloud IDE                 | ✅               | ✅                     | ✅                  | ✅                  |
+| dbt Copilot                   | ✅               | ✅                     | ✅                  | ✅                  |
 | dbt Explorer                  | ✅               | ✅                     | ✅                  | ✅                  |
 | dbt Mesh                      | ✅               | ✅                     | ✅                  | ✅                  |
 | dbt Semantic Layer            | ✅               | ✅ (Upon request)      | ✅                  | ❌                  |

website/vercel.json

@@ -2,6 +2,11 @@
   "cleanUrls": true,
   "trailingSlash": false,
   "redirects": [
+    {
+      "source": "/faqs/API/rotate-token",
+      "destination": "/docs/dbt-cloud-apis/service-tokens#service-token-update",
+      "permanent": true
+    },
     {
       "source": "/styles",
       "destination": "https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/adding-page-components.md",