[BUG] dbt Platform teams miss `DBT_CLOUD_INVOCATION_CONTEXT` env var and more in local development

[boxysean]

Describe the bug
I'm working with two teams who have been using either the dbt Cloud CLI or dbt Studio IDE and testing out dbt Fusion. I have two similar cases:

1. One team has dbt macros that use DBT_CLOUD_INVOCATION_CONTEXT environment variable to set targets and warehouses.
2. A second team usually uses dbt Studio IDE set their own custom variables: DBT_SOURCE_DB, DBT_PREP_DB, etc. that they use in dbt_project.yml. When they tried out dbt Fusion on VSCode, they expected that their dbt Platform env vars would be available to them, and in the interim created a .env file with variables -- but their preference is for these variables to be centrally managed.

In both cases, dbtf (in VSCode) does not recognize the environment variables from dbt Platform.

I've confirmed in dbt Studio with Fusion enabled that DBT_CLOUD_INVOCATION_CONTEXT is enabled. However, in local dev (VSCode) this variable does not appear to be set.

What version of dbt Fusion is this bug in? (find out by running dbt --version)
dbt-fusion 2.0.0-preview.7

Is this a discrepancy between the dbt Fusion Engine and dbt Core? Check one.

• YES
• NO

To Reproduce

• Add a model with contents select {{ env_var('DBT_CLOUD_INVOCATION_CONTEXT') }} as invo_context to a local dbt Fusion project in VSCode.
• Observe the following error: dbt1501: Failed to render SQL invalid operation: 'env_var': environment variable 'DBT_CLOUD_INVOCATION_CONTEXT' not found

Expected behavior
Developers that use dbt Platform have the DBT_CLOUD_INVOCATION_CONTEXT environment variable available in their VSCode local development environment.

Operating System and CPU Type (please complete the following information):
Apple Silicon

[jtcohen6]

As discussed offline - users can programmatically set (or hard-code) values of any environment variables they want, on the CLI or in .env file (to be picked up by the LSP / VSCode extension). That would include setting DBT_CLOUD_INVOCATION_CONTEXT: dev in development contexts.

I'm curious to hear what other sort of information folks would be expecting to access as environment variables! Active project_id, account_id, user_id, ...?

[boxysean]

A little more context:

A team I'm working with told me yesterday it would be beneficial for them to have their env vars from dbt Platform injected into local dev Fusion. They, as data platform maintainers, want to (a) minimize effort to get local dev up-and-running (less copy pasta to .env files) and (b) keep teams in-sync without having to tell them to change their .env files

[davidharting]

RE: env variables

@kendru is working on https://github.com/dbt-labs/fs/issues/6461, which would help out during first-time set up. But I wonder if to fully satisfy this we would need something more robust (Andrew's work lays ground work to be expanded if we want.

RE: DBT_CLOUD_INVOCATION_CONTEXT: agreed with jerco. I don't see fusion or VSCE populating / faking that, but user's can in their shell or VSCode env variables, like jerco said.