Feat(dbt): Add support for on-run-start and on-run-end hooks

[themisvaltinos]

This update adds support for dbt's on-run-start and on-run-end hooks which are defined in dbt_project.yml:

on-run-start: sql-statement | [sql-statement]  
on-run-end: sql-statement | [sql-statement]  

Internally, these are mapped to SQLMesh's before_all and after_all statements

---

As part of this update, the schemas variable is also supported, enabling to grant privileges as you would in dbt with a macro:

{% macro grant_usage_to_schemas(schemas, user) %}
  {% for schema in schemas %}
    GRANT USAGE ON SCHEMA {{ schema }} TO {{ user }};
  {% endfor %}
{% endmacro %}

This macro can then be used in on-run-end:

on-run-end:
  - "{{ grant_usage_to_schemas(schemas, 'user') }}"

---

This is also supported in native SQLMesh projects for before_all and after_all statements:

after_all:
  - "@grant_usage_to_role(@schemas, admin)"

And by defining the corresponding macro:

from sqlmesh import macro

@macro()
def grant_usage_to_role(evaluator, schemas, role):
  if evaluator._environment_naming_info:
    return [
      f"GRANT USAGE ON SCHEMA {schema} TO {role};"
      for schema in schemas
    ]

[erindru]

Looks good to me!

I'm not 100% on how the JinjaMacroRegistry is meant to be constructed but the tests look like they're exercising the right things

[themisvaltinos]

Looks good to me!
I'm not 100% on how the JinjaMacroRegistry is meant to be constructed but the tests look like they're exercising the right things

Thanks for drawing my attention to it! I took a closer look and extended the implementation to also account for multiple projects when constructing and adding the jinja macros to the registry

[izeigerman]

If we access these outside the manifest instance, we shouldn't mark them as private. Or at the very least add a public property method to expose these.

[izeigerman]

Why do we do this gymnastics with root macros?