@Ofek Weiss attached is the log requested, related to the issue I'm having when using "defer to production"

Hi @Jeremy Clayville, great to see you here 🤩 looking into it

Thanks @Ofek Weiss I have a little more info to add on this issue: • Elementary needs to create DBT_MODELS table • When “defer to production” is on, it tries to do this in production (which I don’t have permission to). This is correct…devs should not have the ability to affect production • If I run elementary in dev, then a personal schema is created in the lower environment. Then if I build the model again using “defer to production” , it creates the table correctly in dev instead of prod…and the job finishes successfully So, I think the question is… How do I “defer to production” but exclude elementary while in dev….or, make sure when elementary runs in dev, it stays in dev?

Hi @Jeremy Clayville, if you with for elementary to be enabled\disabled in specific envs, you can use project vars as documented in the FAQ section of our docs (under "Can I disable the

on-run-end

hooks or results uploading?"), for your use case it might look something like this:

vars:
  disable_run_results: "{{ target.name == 'prod' }}"
  disable_tests_results: "{{ target.name == 'prod' }}"
  disable_dbt_artifacts_autoupload: "{{ target.name == 'prod' }}"
  disable_dbt_invocation_autoupload: "{{ target.name == 'prod' }}"

do you think that would work for you?

Hi @Ofek Weiss, thanks for the suggestion, that may work. If we wanted this to run in prod only, this would be set as {{ target.name != 'prod' }}, right?

@Jeremy Clayville yes exactly

Hello @Jeremy Clayville, did this solution work for you or did you find another solution ? it does not work for us (https://elementary-community.slack.com/archives/C02CTC89LAX/p1717429491293629?thread_ts=1692696677.104579&cid=C02CTC89LAX)