Grace Goheen

Hi @ashleemtib, yes! Currently, we're planning to tackle this work for 1.9

You can use the `--exclude-resource-type` flag (docs [here](https://docs.getdbt.com/reference/global-configs/resource-type)) or the associated environment variable `DBT_EXCLUDE_RESOURCE_TYPES` (see [here](https://docs.getdbt.com/reference/global-configs/about-global-configs#:~:text=resource%2Dtype%20(v1.8%2B))).

You can set the environment variable equal to something different in each of your environments. Here's some docs on how [this works in dbt Cloud](https://docs.getdbt.com/docs/build/environment-variables).

We currently use commented-out SQL for our integration tests for hard-coded references, so if we were to make this change we'd need to rethink our tests for this package. `fct_model_6`:...

I think: - we should try to support this - I'm not convinced the suggested interface ``` expect: rows: - {payment_id: 3, dollar: .333} # expected - {payment_id: 4, dollar:...

I'm going to close this in favor of https://github.com/dbt-labs/dbt-core/pull/10244

Hello! Thanks for opening up this issue. We did some [work for 1.6.1 to include semantic models in the docs site](https://github.com/dbt-labs/dbt-docs/issues/431), would you want dimensions included in the semantic models...

Hey! It sounds like your dbt command is completing successfully, when actually the underlying execution statements have not yet completed. Could you give us some more insight into your specific...

Should we also add a new test for this or not necessary?

> I'm of the opinion that access makes the most sense in the context of group definitions or cross project refs, so i'm ok with the setup we have today...