Add some kind CI/CD + tests

Missing BigQuery Adapter in Macro dim_dates for dbt Model dbt_dag_monitoring

Issue Description

The macro dim_dag_monitoring_dates and the macro dim_dag_monitoring_task used in the dbt model dbt_dag_monitoring currently lacks the BigQuery adapter implementation, causing errors when running the model on a BigQuery environment.

Expected Behavior

The macros should be adaptable to different database adapters, including BigQuery. When using the dbt_dag_monitoring model with a BigQuery adapter, it should work seamlessly without causing errors or requiring manual adjustments.

Actual Behavior

When running dbt_dag_monitoring on a BigQuery environment, the following error occurs:

This indicates that the macro dim_dates isn't handling BigQuery correctly, leading to failure when processing date-related operations.

Steps to Reproduce

1. Set up a dbt project with a BigQuery adapter.
2. Include the dbt_dag_monitoring model in your project.
3. Run dbt run.
4. Observe the error caused by the dim_dates macro.

Proposed Solution

Add support for the BigQuery adapter in the dim_dag_monitoring_dates and the dim_dag_monitoring_task macros:

• Change the null, to cast(null as string) as bq null aren't strings.
• Change DOW funtion do daysofweek, as is the native BQ method

Thank you for your attention to this issue. Please let me know if you need additional information or context.

We started this as an Airflow monitoring project but now we`ve expanded to dags tooling in general.

We should rename specific Airflow names to some dag terminology e.g. change the name of the repo itself from dbt-airflow-monitoring to dbt-dag-monitoring

Today we can only enable one of the three options, sometimes we will have more than one e.g. both databricks and adf

each dag source has its own states, we should normalize this to pre defined values such as
success, fail and in_progress

ex for databricks and adf sources:

The command dbt build isn't taking the information from the folder integration_tests

maybe we should change the unique key for pipelines instead of deduping here. etag is the pipeline version, we are using it for deduping

(suggestion given by vitoravancini - extracted from README.md)