-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DbtTaskGroup should not need dag=dag
#118
Comments
josh-fell
added a commit
to josh-fell/astronomer-cosmos
that referenced
this issue
Feb 4, 2023
Closes: astronomer#118 Typically when authoring with TaskGroups in Airflow, users will not explicitly pass a DAG object but rather set the TaskGroup within a DAG context manager. Making the `dag` arg optional in the CosmosTaskGroup will allow the same authoring practice. In Airflow, if a `dag` arg is not passed to a TaskGroup, behind the scenes `DagContext.get_current_dag()` is called to retrieve the DAG object. Since CosmosTaskGroup pushes the `dag` arg to its super class, and early enough in construction, the same functional behavior is triggered.
josh-fell
added a commit
to josh-fell/astronomer-cosmos
that referenced
this issue
Feb 4, 2023
Closes: astronomer#118 Typically when authoring with TaskGroups in Airflow, users will not explicitly pass a DAG object but rather set the TaskGroup within a DAG context manager. Making the `dag` arg optional in the CosmosTaskGroup will allow the same authoring practice. In Airflow, if a `dag` arg is not passed to a TaskGroup, behind the scenes `airflow.models.DagContext.get_current_dag()` is called to retrieve the DAG object. Since CosmosTaskGroup pushes the `dag` arg to its super class, and early enough in construction, the same functional behavior is triggered.
chrishronek
added a commit
that referenced
this issue
Feb 6, 2023
Closes: #118 Typically when authoring with TaskGroups in Airflow, users will not explicitly pass a DAG object but rather set the TaskGroup within a DAG context manager. Making the `dag` arg optional in the CosmosTaskGroup will allow the same authoring practice. In Airflow, if a `dag` arg is not passed to a TaskGroup, behind the scenes `airflow.models.DagContext.get_current_dag()` is called to retrieve the DAG object. Since CosmosTaskGroup pushes the `dag` arg to its super class, and early enough in construction, the same functional behavior is triggered. Co-authored-by: Chris Hronek <31361051+pohek321@users.noreply.github.com>
josh-fell
added a commit
to josh-fell/astronomer-cosmos
that referenced
this issue
Feb 6, 2023
Closes: astronomer#118 Typically when authoring with TaskGroups in Airflow, users will not explicitly pass a DAG object but rather set the TaskGroup within a DAG context manager. Making the `dag` arg optional in the CosmosTaskGroup will allow the same authoring practice. In Airflow, if a `dag` arg is not passed to a TaskGroup, behind the scenes `airflow.models.DagContext.get_current_dag()` is called to retrieve the DAG object. Since CosmosTaskGroup pushes the `dag` arg to its super class, and early enough in construction, the same functional behavior is triggered.
josh-fell
added a commit
to josh-fell/astronomer-cosmos
that referenced
this issue
Feb 6, 2023
Closes: astronomer#118 Typically when authoring with TaskGroups in Airflow, users will not explicitly pass a DAG object but rather set the TaskGroup within a DAG context manager. Making the `dag` arg optional in the CosmosTaskGroup will allow the same authoring practice. In Airflow, if a `dag` arg is not passed to a TaskGroup, behind the scenes `airflow.models.DagContext.get_current_dag()` is called to retrieve the DAG object. Since CosmosTaskGroup pushes the `dag` arg to its super class, and early enough in construction, the same functional behavior is triggered.
chrishronek
pushed a commit
that referenced
this issue
Feb 6, 2023
Closes: #118 Typically when authoring with TaskGroups in Airflow, users will not explicitly pass a DAG object but rather set the TaskGroup within a DAG context manager. Making the `dag` arg optional in the CosmosTaskGroup will allow the same authoring practice. In Airflow, if a `dag` arg is not passed to a TaskGroup, behind the scenes `airflow.models.DagContext.get_current_dag()` is called to retrieve the DAG object. Since CosmosTaskGroup pushes the `dag` arg to its super class, and early enough in construction, the same functional behavior is triggered.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Like other task groups, if using the
dag
context manager, theDbtTaskGroup
shouldn't need thedag=dag
argument passed in.The text was updated successfully, but these errors were encountered: