DO NOT MERGE - Release 1.2.5 #708
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<!--pre-commit.ci start--> updates: - [github.com/pre-commit/mirrors-mypy: v1.5.1 → v1.6.0](pre-commit/mirrors-mypy@v1.5.1...v1.6.0) <!--pre-commit.ci end--> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> (cherry picked from commit 28268dc)
…ags (#606) Before, when using Cosmos custom selector, it expected an exact match of all *tags*. Example: `model1` with tags `tag1` and `tag2` would only be selected/excluded if the select/exclude statement in the `RenderConfig` was set to `select=["tag:tag1,tag:tag2"]`. It would not be selected if the `RenderConfig` had `select=["tag:tag1"]` or `select=["tag:tag2"]` only. (cherry picked from commit a433f15)
…ER_EACH (#599) Previously Cosmos would only create a task group when using `TestBehavior.AFTER_EACH` for nodes of the type `DbtResourceType.MODEL`. This change adds the same behavior to snapshots and seeds. For this to work as expected with sources, we would need to create a default operator to handle `DbtResourceType.SOURCE`, which is outside the scope of the current ticket. Once this operator exists, sources will also lead to creating a task group. All the test selectors were tested successfully with dbt 1.6. This screenshot illustrates the validation of this feature, with an adapted version of Jaffle Shop: <img width="1502" alt="Screenshot 2023-10-13 at 19 43 52" src="https://github.com/astronomer/astronomer-cosmos/assets/272048/893ac557-1846-4ed1-b5e2-913a7bd38485"> The modifications that were done to jaffle_shop were: Appended the following lines to `dev/dags/dbt/jaffle_shop/models/schema.yml`: ``` seeds: - name: raw_customers description: Raw data from customers columns: - name: id tests: - unique - not_null snapshots: - name: orders_snapshot description: Snapshot of orders columns: - name: orders_snapshot.order_id tests: - unique - not_null ``` And created the file `dev/dags/dbt/jaffle_shop/snapshots/orders_snapshot.sql` with: ``` {% snapshot orders_snapshot %} {{ config( target_database='postgres', target_schema='public', unique_key='order_id', strategy='timestamp', updated_at='order_date', ) }} select * from {{ ref('jaffle_shop', 'orders') }} {% endsnapshot %} ``` Closes: #474 (cherry picked from commit e09ac6d)
…ect-selection buildable) (#613) When running tests with dbt, dbt allows users to run them in different [modes](https://docs.getdbt.com/reference/node-selection/test-selection-examples#indirect-selection). As described in the linked dbt documentation: > The "buildable", "cautious", and "empty" modes can be useful in environments when you're only building a subset of your DAG, and you want to avoid test failures in "eager" mode caused by unbuilt resources. Exactly this is the case when using cosmos when running tests with `AFTER_EACH` behaviour. When a tests depends on multiple models, a test can result in an error, because the dependent model was not run yet. Example: with a simple DAG like this `model1 -> model2`, and a test `rc_test` set up to test row-count being equal between `model1` and `model2` an error might occur when we run operations in the following order: 1. `dbt run --model model1` 2. `dbt test --model model1` -> this will result in an error, if the row count has changed between the last and this run. adding the argument `--indirect-selection buildable` in step 2 will avoid actually executing the test there, because dbt makes sure to run the test only if *all* dependent models are upstream. So we can continue without an error: 3. `dbt run --model model2` 4. `dbt test --model model2 --indirect-selection buildable` -> this will actually run the test `rc_test` in this step. By adding `--indirect-selection buildable` we have avoided running the test `rc_test` twice (in both the `model1` DagGroup and `model2` DagGroup), running it only once in `model2`. (cherry picked from commit 1bf3a3e)
…port dbt_project_path=None (#605) As part of the changes made #581, some downstream logic was missed relating to the handling of a None and String-based project dir. This MR attempts to remedy this issue by adding down steam support for the project dir being None (including generation of exceptions and guarding), as well as some property reference changes in the converter. Closes: #601 Co-authored-by: tabmra <tabmra@rwwa.com.au> (cherry picked from commit 2f8d0e2)
<!--pre-commit.ci start--> updates: - [github.com/astral-sh/ruff-pre-commit: v0.0.292 → v0.1.1](astral-sh/ruff-pre-commit@v0.0.292...v0.1.1) - [github.com/psf/black: 23.9.1 → 23.10.0](psf/black@23.9.1...23.10.0) - [github.com/pre-commit/mirrors-mypy: v1.6.0 → v1.6.1](pre-commit/mirrors-mypy@v1.6.0...v1.6.1) <!--pre-commit.ci end--> Co-authored-by: Tatiana Al-Chueyr <tatiana.alchueyr@gmail.com> (cherry picked from commit 8b96120)
When checking the latest test runs in several branches for**Run-Integration-Tests (3.8, 2.7)**, example: https://github.com/astronomer/astronomer-cosmos/actions/runs/6612130380/job/17957443769?pr=605#logs I noticed that `cosmos_manifest_example` was not being run. This PR solves this issue. (cherry picked from commit 9056125)
As of Cosmos 1.2.0, whenever imported, the library would print a long stack trace related to Openlineage if it was not available as a warning. Change only to print the stack trace if DEBUG log mode is used. (cherry picked from commit a4aa5cc)
…fileMapping` is used (#625) Since #489 was merged, the behavior of `LoadMode.AUTOMATIC` changed to generate a `profiles.yml` file if the file didn't exist. However, we forgot to remove the previously necessary condition for being able to run `LoadMode.DBT_LS` (having the `profiles.yml` file). This leads to inconsistent behaviour in Cosmos when using `LoadMode.AUTOMATIC` and the `manifest.json` was not available: 1. If the user used a `ProfileConfig` with `profiles_yml_filepath`, it would use `LoadMode.DBT_LS` 2. If the user used a `ProfileConfig` with a ProfileMapping class, it would unnecessarily use `LoadMode.CUSTOM` This PR fixes the behaviour to attempt to use `LoadMode.DBT_LS` regardless of how the `ProfileConfig` was set. (cherry picked from commit ad7dcf0)
) Before this change, Cosmos failed to run if there is an issue in the openlineage-common parsing of the dbt project due to a jinja2 exception, which did not happen when running the dbt command by itself: #612 (comment) ``` File "/usr/local/lib/python3.11/site-packages/cosmos/operators/local.py", line 268, in calculate_openlineage_events_completes openlineage_processor = DbtLocalArtifactProcessor( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openlineage/common/provider/dbt/local.py", line 57, in __init__ dbt_project = self.load_yaml_with_jinja( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openlineage/common/provider/dbt/local.py", line 157, in load_yaml_with_jinja return self.render_values_jinja( ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openlineage/common/provider/dbt/local.py", line 180, in render_values_jinja parsed_dict[key] = cls.render_values_jinja( ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openlineage/common/provider/dbt/local.py", line 180, in render_values_jinja parsed_dict[key] = cls.render_values_jinja( ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openlineage/common/provider/dbt/local.py", line 180, in render_values_jinja parsed_dict[key] = cls.render_values_jinja( ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/openlineage/common/provider/dbt/local.py", line 190, in render_values_jinja return environment.from_string(value).render() # type: ignore ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/jinja2/environment.py", line 1301, in render self.environment.handle_exception() File "/usr/local/lib/python3.11/site-packages/jinja2/environment.py", line 936, in handle_exception raise rewrite_traceback_stack(source=source) File "<template>", line 1, in top-level template code jinja2.exceptions.UndefinedError: 'run_started_at' is undefined ``` Closes: #612 Relates to: OpenLineage/OpenLineage#2212 (cherry picked from commit 4c65f25)
Bug fixes * Resolve errors occurring when `dbt_project_path` is str and partial support `dbt_project_path=None` by @MrBones757 in #605 * Fix running dbt tests that depend on multiple models (support `--indirect-selection` buildable) by @david-mag in #613 * Add tests to sources, snapshots and seeds when using `TestBehavior.AFTER_EACH` by @tatiana in #599 * Fix custom selector when select has a subset of tags of the models' tags by @david-mag in #606 * Fix `LoadMode.AUTOMATIC` behaviour to use `LoadMode.DBT_LS` when `ProfileMapping` is used by @tatiana in #625 * Fix failure if `openlineage-common` raises a jinja exception by @tatiana in #626 Others * Update contributing guide docs by @raffifu in #591 * Remove unnecessary stack trace from Cosmos initialization by @tatiana in #624 * Fix running test that validates manifest-based DAGs by @tatiana in #619 * pre-commit updates in #604 and #621
…nd `LoadMethod.CUSTOM` (#615) Resolving issues with the DBT_MANIFEST/CUSTOM load methods when the has_test attribute is not assigned to the node correctly. ## Description When a tag selector is used, all tests are filtered out because of the DbtResourceType.TEST node does not have any information about tags. To bypass this limitation - tags are assigned to tests based on their parent model. ## Related Issue(s) Closes: #580 Co-authored-by: edgarasnavickas <edgaras.navickas@kevin.eu> (cherry picked from commit 58de67e)
<!--pre-commit.ci start--> updates: - [github.com/astral-sh/ruff-pre-commit: v0.1.1 → v0.1.3](astral-sh/ruff-pre-commit@v0.1.1...v0.1.3) - [github.com/psf/black: 23.10.0 → 23.10.1](psf/black@23.10.0...23.10.1) <!--pre-commit.ci end--> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> (cherry picked from commit 8c89d8b)
) Reduce Cosmos code complexity from 18 to 10, automating checks as part of the CI. ```shell ❯ pre-commit run flake8 --all-files flake8...................................................................Failed - hook id: flake8 - exit code: 1 cosmos/dbt/graph.py:134:5: C901 'DbtGraph.load_via_dbt_ls' is too complex (16) cosmos/dbt/parser/project.py:136:5: C901 'DbtModel.__post_init__' is too complex (18) cosmos/dbt/parser/project.py:346:5: C901 'LegacyDbtProject._handle_config_file' is too complex (15) cosmos/dbt/selector.py:87:1: C901 'select_nodes_ids_by_intersection' is too complex (16) ``` Closes: #525 (cherry picked from commit f9809a8)
To run the integration tests locally without errors, developers have to
set more environment variables than the ones that are currently in the
docs. If these were excluded, they would get errors like:
```shell
tests/test_example_dags_no_connections.py:59: in <module>
@pytest.mark.parametrize("dag_id", get_dag_ids())
tests/test_example_dags_no_connections.py:54: in get_dag_ids
dag_bag = get_dag_bag()
tests/test_example_dags_no_connections.py:49: in get_dag_bag
assert not db.import_errors
E AssertionError: assert not {'/Users/justin.bandoro/astronomer-cosmos/dev/dags/example_cosmos_python_models.py': 'Traceback (most recent call last...ema.yml from project jaffle_shop: Parsing Error\n Env var required but not provided: \'DATABRICKS_CLUSTER_ID\'\n\n'}
E + where {'/Users/justin.bandoro/astronomer-cosmos/dev/dags/example_cosmos_python_models.py': 'Traceback (most recent call last...ema.yml from project jaffle_shop: Parsing Error\n Env var required but not provided: \'DATABRICKS_CLUSTER_ID\'\n\n'} = <airflow.models.dagbag.DagBag object at 0x1579cd000>.import_errors
```
(cherry picked from commit 156e51d)
At the moment, all PRs are failing due to issues with integration tests
not being able to run. An example of error message:
```
FAILED tests/test_example_dags.py::test_example_dag[extract_dag] - assert not {'/home/runner/work/astronomer-cosmos/astronomer-cosmos/dev/dags/example_cosmos_python_models.py': 'Traceback (most recent call last):\n File "/opt/hostedtoolcache/Python/3.9.18/x64/lib/python3.9/selectors.py", line 416, in select\n fd_event_list = self._selector.poll(timeout)\n File "/home/runner/.local/share/hatch/env/virtual/astronomer-cosmos/Za_bFbg4/tests.py3.9-2.4/lib/python3.9/site-packages/airflow/utils/timeout.py", line 69, in handle_timeout\n raise AirflowTaskTimeout(self.error_message)\nairflow.exceptions.AirflowTaskTimeout: DagBag import timeout for /home/runner/work/astronomer-cosmos/astronomer-cosmos/dev/dags/example_cosmos_python_models.py after 30.0s.\nPlease take a look at these docs to improve your DAG import time:\n* https://airflow.apache.org/docs/apache-airflow/2.4.0/best-practices.html#top-level-python-code\n* https://airflow.apache.org/docs/apache-airflow/2.4.0/best-practices.html#reducing-dag-complexity, PID: 2558\n'}
```
This issue relates to #520 - something we'll be soon working on.
In the meantime, we're increasing the DAG Parsing time in the CI - so
our tests can run again.
We should also review how we run the integration tests - we probably do
not need to run all DAGs against the Python x Airflow matrix, and we
could parallelise some of those.
(cherry picked from commit 358f4b0)
1) Airflow 2.4 & Werkzeug =>3 issue
Our integration tests failed for Airflow 2.4 and under since Werkzeug
3.0 and higher during `airflow db init` with:
```
Traceback (most recent call last):
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/bin/airflow", line 10, in <module>
sys.exit(main())
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/airflow/__main__.py", line 39, in main
args.func(args)
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/airflow/cli/cli_parser.py", line 52, in command
return func(*args, **kwargs)
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/airflow/cli/commands/db_command.py", line 37, in initdb
db.initdb()
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/airflow/utils/session.py", line 75, in wrapper
return func(*args, session=session, **kwargs)
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/airflow/utils/db.py", line 681, in initdb
_create_db_from_orm(session=session)
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/airflow/utils/db.py", line 653, in _create_db_from_orm
from airflow.www.fab_security.sqla.models import Model
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/airflow/www/fab_security/sqla/models.py", line 27, in <module>
from flask_appbuilder.models.sqla import Model
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_appbuilder/__init__.py", line 5, in <module>
from .api import ModelRestApi # noqa: F401
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_appbuilder/api/__init__.py", line 24, in <module>
from ..baseviews import AbstractViewApi
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_appbuilder/baseviews.py", line 22, in <module>
from .forms import GeneralModelConverter
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_appbuilder/forms.py", line 3, in <module>
from flask_wtf import FlaskForm
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_wtf/__init__.py", line 3, in <module>
from .recaptcha import *
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_wtf/recaptcha/__init__.py", line 2, in <module>
from .fields import *
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_wtf/recaptcha/fields.py", line 3, in <module>
from . import widgets
File "/Users/tati/Library/Application Support/hatch/env/virtual/astronomer-cosmos/4VBJdS-x/tests.py3.10-2.4/lib/python3.10/site-packages/flask_wtf/recaptcha/widgets.py", line 2, in <module>
from werkzeug.urls import url_encode
```
Which led to no Airflow tables being created during the tests
initialisation.
2) Example DAG `cosmos_manifest_example` relying on pre-existing data
The selection statement used in the `cosmos_manifest_example` expected
data to pre-exist in the database. This probably worked before because
of the order of the tests run - and it broke up recently once this test
started running before others.
Since tests should be self-contained, the filter clause was changed so
this DAG execution becomes independent.
(cherry picked from commit 14b3090)
… Rendering and Execution (#634) This MR finishes the work that was started in #605 to add full support for ProjectConfig.dbt_project_path = None, and implements #568. Within this PR, several things have been updated: 1 - Added project_path fields to RenderConfig and ExecutionConfig 2 - Simplified the consumption of RenderConfig in the dbtGraph class 3 - added option to configure different dbt executables for Rendering vs Execution. Closes: #568 (cherry picked from commit b64eb9a)
Bug fixes * Support ProjectConfig.dbt_project_path = None & different paths for Rendering and Execution by @MrBones757 in #634 * Fix adding test nodes to DAGs built using LoadMethod.DBT_MANIFEST and LoadMethod.CUSTOM by @edgga in #615 Others * Add pre-commit hook for McCabe max complexity check and fix errors by @jbandoro in #629 * Update contributing docs for running integration tests by @jbandoro in #638 * Fix CI issue running integration tests by @tatiana in #640 and #644 * pre-commit updates in #637
…AL` (#659) Extends the local operator when running `dbt deps` with the provides profile flags. This makes the logic consistent between DAG parsing and task running as referenced below https://github.com/astronomer/astronomer-cosmos/blob/8e2d5908ce89aa98813af6dfd112239e124bd69a/cosmos/dbt/graph.py#L247-L266 Closes: #658 (cherry picked from commit 6e41471)
Since Cosmos 1.2.2 users who used `ExecutionMode.DBT_LS` (directly or
via `ExecutionMode.AUTOMATIC`) and set
`ExecutionConfig.dbt_executable_path` (most, if not all, Astro CLI
users), like:
```
execution_config = ExecutionConfig(
dbt_executable_path = f"{os.environ['AIRFLOW_HOME']}/dbt_venv/bin/dbt",
)
```
Started facing the issue:
```
Broken DAG: [/usr/local/airflow/dags/my_example.py] Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/cosmos/dbt/graph.py", line 178, in load
self.load_via_dbt_ls()
File "/usr/local/lib/python3.11/site-packages/cosmos/dbt/graph.py", line 233, in load_via_dbt_ls
raise CosmosLoadDbtException(f"Unable to find the dbt executable: {self.dbt_cmd}")
cosmos.dbt.graph.CosmosLoadDbtException: Unable to find the dbt executable: dbt
```
This issue was initially reported in the Airflow #airflow-astronomer
Slack channel:
https://apache-airflow.slack.com/archives/C03T0AVNA6A/p1699584315506629
The workaround to avoid this error in Cosmos 1.2.2 and 1.2.3 is to set
the `dbt_executable_path` in the `RenderConfig`:
```
render_config=RenderConfig(dbt_executable_path = f"{os.environ['AIRFLOW_HOME']}/dbt_venv/bin/dbt",),
```
This PR solves the bug from Cosmos 1.2.4 onwards.
(cherry picked from commit 2b61364)
Update `DbtLocalBaseOperator` code to store `compiled_sql` prior to exception handling so that when a task fails, the `compiled_sql` can still be reviewed. In the process found and fixed a related bug where `compiled_sql` was being dropped on some operations due to the way that the `full_refresh` field was being added to the `template_fields`. Closes #369 Fixes bug introduced in #623 where compiled_sql was being lost in `DbtSeedLocalOperator` and `DbtRunLocalOperator` Co-authored-by: Andrew Greenburg <agreenburg@vergeventures.net> (cherry picked from commit ee91ece)
Bug fixes * Store `compiled_sql` even when task fails by @agreenburg in #671 * Refactor `LoadMethod.LOCAL` to use symlinks instead of copying directory by @jbandoro in #660 * Fix 'Unable to find the dbt executable: dbt' error by @tatiana in #666 * Fix installing deps when using `profile_mapping` & `ExecutionMode.LOCAL` by @joppevos in #659 Others * Docs fix: add execution config to MWAA code example by @ugmuka in #674
(cherry picked from commit 7ec7410)
(cherry picked from commit 709ba44)
Current version, cosmos will got bug `Not found node` because it run
with alias selection as: `--models customers_abc_v1 ` and `--models
customers_abc_v2` .
I propose to parsing node selection in `unique_id` instead of using
`alias` .
So node selection should be: `unique_id.split('.', 2)[2]` , reference to
[function](https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/contracts/graph/node_args.py#L26)
and [resource-details
document](https://docs.getdbt.com/reference/artifacts/manifest-json#resource-details).
In addition, with this change help cosmos also support versioned models
on dbt-core `>=1.5.0` instead `>=1.6.0` as current version.
Cosmos will support dynamic aliases and versioned models
Closes: #636
(cherry picked from commit e23a445)
To make `on_warning_callback` work with pod operators, we need to read the logs of the dbt test runs. This is done by ensuring the pod is kept alive, and `on_success_callback` the log is read and analysed for warnings. Afterwards, the pod is cleaned up based on the original settings from the user. If `on_warning_callback` is not set, everything stays the way it always was. This feature only work with `apache-airflow-providers-cncf-kubernetes >= 7.4.0`. (cherry picked from commit 0b538a5)
After speaking with customers, it looks like it would be more clear to flag our examples in the dev folder in the README. Co-authored-by: Julian LaNeve <lanevejulian@gmail.com> (cherry picked from commit 24aa38e)
The example DAG we had declared in our README and index page was incompatible with the latest versions of Cosmos. An Astronomer customer reported this, and we didn't realise it because those code excerpts were not executed. This PR changes the references to an example DAG run as part of our integration tests. As a follow-up, we should try to avoid this redundancy between `README.rst` and `index.rst` - which I logged as follow up ticket in #704. (cherry picked from commit 2617449)
Fix broken docs sample DAG image, due to different syntax to render images between Github and Sphinx. (cherry picked from commit bc8a309)
…"method" (#702) The issue is described in #696 which was discovered when a user was creating a ProfileConfig with `GoogleCloudServiceAccountDictProfileMapping(profile_args={"method": "service-account"})` which was overriding the dbt profile method: https://github.com/astronomer/astronomer-cosmos/blob/24aa38e528e299ef51ca6baf32f5a6185887d432/cosmos/profiles/bigquery/service_account_keyfile_dict.py#L21 when the profile args are mapped to the created profile below: https://github.com/astronomer/astronomer-cosmos/blob/24aa38e528e299ef51ca6baf32f5a6185887d432/cosmos/profiles/bigquery/service_account_keyfile_dict.py#L42-L52 This is not an issue with the profile mapping example above and could happen with any profile mapping by changing the "type" from `dbt_profile_type` or "method" (if used) from `dbt_profile_method` in the class. The fix in this PR is to not allow args with "type" or "method" that are different from the class variables in `profile_args`. I think this is better than logging a warning because if either of those fields are different the dbt run with the created profile will fail anyways. This also allows backwards compatibility in the case users have these already set in their profile args and it matches the class variables. Closes #696 (cherry picked from commit 8f7a04b)
Bug fixes * Fix running models that use alias while supporting dbt versions by @binhnq94 in #662 * Make profiles_yml_path optional for ExecutionMode.DOCKER and KUBERNETES by @MrBones757 in #681 * Prevent overriding dbt profile fields with profile args of type or method by @jbandoro in #702 * Fix LoadMode.DBT_LS fail when dbt outputs WarnErrorOptions by @adammarples in #692 * Add support for env vars in RenderConfig for dbt ls parsing by @jbandoro in #690 * Add support for Kubernetes on_warning_callback by @david-mag in #673 * Fix ExecutionConfig.dbt_executable_path to use ``default_factory`` by @jbandoro in #678 Others * Docs fix: example DAG in the README and docs/index by @tatiana in #705 * Docs improvement: highlight DAG examples in README by @iancmoritz and @jlaneve in #695
👷 Deploy Preview for amazing-pothos-a3bca0 processing.
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #708 +/- ##
==========================================
- Coverage 93.13% 92.71% -0.42%
==========================================
Files 51 51
Lines 2053 2168 +115
==========================================
+ Hits 1912 2010 +98
- Misses 141 158 +17 ☔ View full report in Codecov by Sentry. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bug fixes
profiles_yml_pathoptional forExecutionMode.DOCKERandKUBERNETESby @MrBones757 in Makeprofiles_yml_pathoptional forExecutionMode.DOCKERandKUBERNETES#681LoadMode.DBT_LSfail when dbt outputsWarnErrorOptionsby @adammarples in Return code or error ignores WarnErrorOptions #692RenderConfigfor dbt ls parsing by @jbandoro in Add support for env vars in RenderConfig for dbt ls parsing #690on_warning_callbackby @david-mag in Kubernetes on warning callback #673default_factoryby @jbandoro in Fix ExecutionConfig.dbt_executable_path to use default_factory #678Others