Merge branch 'current' into dt-optimize-img

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/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/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/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)      | ✅                  | ❌                  |