fix: dependencies installation with project level variables

[AlexandrKhabarov]

Description

Failed at runtime phase during dependencies installation if project level variables are used

dbt deps \
    --target $FLOPPA_TARGET \
    --profiles-dir $FLOPPA_FOLDER \
    --project-dir $FLOPPA_FOLDER
14:43:11  Running with dbt=1.8.9
14:43:11  Encountered an error:
Compilation Error
  Could not render ingestion_date = '{{ var("ingestion_date") }}': Required var 'ingestion_date' not found in config:
  Vars supplied to <Configuration> = {}

Related Issue(s)

Breaking Change?

No breaking changes

Checklist

• I have made corresponding changes to the documentation (if required)
• I have added tests that prove my fix is effective or that my feature works

[netlify]

✅ Deploy Preview for sunny-pastelito-5ecb04 canceled.

Name	Link
🔨 Latest commit	7af101e
🔍 Latest deploy log	https://app.netlify.com/projects/sunny-pastelito-5ecb04/deploys/685815617ce45f0008f36abd

[netlify]

✅ Deploy Preview for sunny-pastelito-5ecb04 canceled.

Name	Link
🔨 Latest commit	64b996d
🔍 Latest deploy log	https://app.netlify.com/projects/sunny-pastelito-5ecb04/deploys/685978c6b18ec40008b5a048

[AlexandrKhabarov]

@tatiana can you take a look, please?

[tatiana]

Hi @AlexandrKhabarov thank you very much for reporting this issue and fixing it.

Would it be possible to add a test to confirm that when using local execution mode these flags are being passed, as desired?

Also, which LoadMode are you using? We may not be handling this use case when installing deps in LoadMode.DBT_LS (

astronomer-cosmos/cosmos/dbt/graph.py

Lines 645 to 652 in e45bf11

	def run_dbt_deps(self, dbt_cmd: str, dbt_project_path: Path, env: dict[str, str]) -> None:
	"""
	Given the dbt command path and the dbt project path, build and run the dbt deps command.
	"""
	deps_command = [dbt_cmd, "deps"]
	deps_command.extend(self.local_flags)
	self._add_vars_arg(deps_command)
	run_command(deps_command, dbt_project_path, env, self.render_config.invocation_mode, self.log_dir)

). If you could confirm if that is the case, we could create a follow-up ticket to address this.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.01%. Comparing base (389e1bf) to head (64b996d).
Report is 9 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1822   +/-   ##
=======================================
  Coverage   98.01%   98.01%           
=======================================
  Files          85       85           
  Lines        5290     5290           
=======================================
  Hits         5185     5185           
  Misses        105      105           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[AlexandrKhabarov]

Hello @tatiana

I think that such test exists - https://github.com/astronomer/astronomer-cosmos/blob/main/tests/dbt/test_graph.py#L1837

I am using LoadMode.AUTOMATIC. DBT_LS is part of it

[AlexandrKhabarov]

Also, I created a PR in a past to fix problem with parsing - #1543

[tatiana]

Thank you very much, @AlexandrKhabarov !

The test https://github.com/astronomer/astronomer-cosmos/blob/main/tests/dbt/test_graph.py#L1837 covers the issue in the DAG parsing/rendering while converting during the dbt ls command execution - so apparently the problem was already solved there.

Since you fixed the behaviour in the local operator execution, it may be worth adapting or adding a test in https://github.com/astronomer/astronomer-cosmos/blob/main/tests/operators/test_local.py
To make sure we don't cause any regressions, and this fix remains there.

It could be a very similar test to what you did in the test tests/operators/test_virtualenv.py validates that --vars were not set. In the case of the local operator, we'd like to confirm that we're setting the correct arguments when trying to run deps from there.