Hi everyone, I am using the Elementary library, which triggers pre-hooks and post-hooks on every run of DBT. I am looking for a way to execute DBT commands without triggering these hooks because I want to create a DBT manifest that doesn't contain information related to Elementary. Is there a way to disable these hooks temporarily or configure DBT/Elementary to skip them? Thanks in advance for your help!

We have the following config in `dbt_project.yml`:

vars:
  elementary:
    disable_dbt_artifacts_autoupload: "{{ target.name.lower() not in ['dev', 'prod'] }}"
    disable_dbt_invocation_autoupload: "{{ target.name.lower() not in ['dev', 'prod'] }}"
    disable_run_results: "{{ target.name.lower() not in ['dev', 'prod'] }}"
    # Disabling test results will lead to abandoned tables in Elementary schema (created by Elementary tests)
    #disable_tests_results: "{{ target.name.lower() not in ['dev', 'prod'] }}"

Check Elementary docs for more details: https://docs.elementary-data.com/dbt/on-run-end_hooks

@Denis Kokorin Which one of this remove all elementary models from the manifests? I added this to my `dbt_project.yml`:

ars:
  disable_dbt_artifacts_autoupload: true

But in the manifest and also in the doc I still see the elementary models

Any model is described in manifest despite if it is enabled or not. So if you add Elementary package to your project - all models will appear in manifest. You asked:

Is there a way to disable these hooks temporarily or configure DBT/Elementary to skip them?

So my answer was to this question. Regarding this:

I want to create a DBT manifest that doesn't contain information related to Elementary.

Could you give more context, why you want to exclude models from manifest? What do you do with the manifest?

@Denis Kokorin Sorry, you are right. My request was related to hooks. I need to work with the manifest.json to generate Airflow DAG tasks for each DBT model. It would be helpful if the manifest didn't contain any information related to Elementary.

I see, you are probably inspired by Astronomer's post showing Airflow DAG matching DBT data 1 to 1. And my advice are strongly against it (we tried it and didn't like it). 1. Having BashOperator for every model and test will be slow: you have to compile a project each time. Caching DBT artifacts can be helpful, but DBT startup time is about several seconds. 2. Airflow DAG will quickly become a mess of models and tests. How many DBT nodes you have now? 3. DBT is not only models, and tests but also seeds and snapshots, you will have to take them into account in Airflow DAG (if you use them) 4. And the most important: Elementary uploads some data after every run, test or build command. So you will run elementary hooks for every DBT node and not once for a project

Thank u for the adivece! I have more cleare some problem that I didn't see

None of the problems above will be solved with per-model/per-test tasks in Airflow DAG. We do: 1. dbt source freshness 2. Upload source freshness using Elementary CLI (on-run-end hooks are invoked only in DBT 1.8, but Elementary doesn't support it yet) 3. dbt build 4. Run Elementary CLI to build a Report or monitor results