No abstraction covers every case. We should expose underlying primitives when you need them. A raw or overrides block in YAML where users can pass arbitrary Terraform resource arguments that aren't yet modeled in your schema would give us an escape hatch, reduce the pressure to model every edge case, and make the module more future-proof against new dbt Cloud provider features.
I think the simplest answer to this is..just define your own HCL alongside this YAML? We should document how a user can do that though, which is probably what this issue is about. We may require some updates on what we output so those IDs are available to users, but this is the majority of what we should document.
The ergonomics matter a lot here. Are the outputs indexed by YAML keys? like module.dbt_cloud.environments["analytics_prod"].id
No abstraction covers every case. We should expose underlying primitives when you need them. A raw or overrides block in YAML where users can pass arbitrary Terraform resource arguments that aren't yet modeled in your schema would give us an escape hatch, reduce the pressure to model every edge case, and make the module more future-proof against new dbt Cloud provider features.
I think the simplest answer to this is..just define your own HCL alongside this YAML? We should document how a user can do that though, which is probably what this issue is about. We may require some updates on what we output so those IDs are available to users, but this is the majority of what we should document.
The ergonomics matter a lot here. Are the outputs indexed by YAML keys? like
module.dbt_cloud.environments["analytics_prod"].id