feat: support operator_aliases for short operator names in YAML configs

[Aaditya-git]

Summary

Closes #58

Adds support for operator_aliases in defaults.yml (or the default: section of a dag YAML), so users can write short operator names instead of full dotted import paths.

Before:

tasks:
  - task_id: task_1
    operator: airflow.operators.bash.BashOperator
    bash_command: echo 1

After:

# defaults.yml
operator_aliases:
  - operator_alias: BashOperator
    operator_path: airflow.operators.bash.BashOperator

# dag YAML
tasks:
  - task_id: task_1
    operator: BashOperator
    bash_command: echo 1

Full dotted paths continue to work unchanged for backward compatibility.

Changes

• dagfactory/dagbuilder.py: added _resolve_operator_alias() static method and call it before make_task() in build()
• dagfactory/dagfactory.py: propagate operator_aliases from defaults.yml into default_config so DagBuilder can access it
• dev/dags/defaults.yml: added example operator_aliases entries
• tests/test_dagbuilder.py: 5 new tests covering alias resolution, passthrough for full paths, unknown aliases, and end-to-end DAG build with alias

Test plan

• test_resolve_operator_alias_returns_full_path: alias resolves to the correct full path
• test_resolve_operator_alias_passthrough_full_path: existing full paths pass through unchanged
• test_resolve_operator_alias_unknown_alias_passthrough: unknown alias returns as-is (no error)
• test_resolve_operator_alias_empty_aliases: empty alias list is safe
• test_build_dag_with_operator_alias: end-to-end, builds a DAG using a short alias name

[tatiana]

Could we update this to the current Airflow 3 standard-provider imports, e.g. airflow.providers.standard.operators.bash.BashOperator and airflow.providers.standard.operators.python.PythonOperator, or split the example by Airflow version?

[tatiana]

Please add a DAGFactory-level test for aliases propagated from defaults.yml / global defaults. The current tests inject aliases directly into DagBuilder’s default_config, so they do not test the new propagation code in dagfactory/dagfactory.py.

[tatiana]

It could be something along the lines:

    config = {
        "test_dag": {
            "tasks": [
                {
                    "task_id": "task_1",
                    "operator": "BashOperator",
                    "bash_command": "echo 1",
                }
            ]
        }
    }

    td = _DagFactory(config_dict=config)

And confirming the expected operator was instantiated within td.build_dags()

[Aaditya-git]

Acknowledged, and will start working on this.

[Aaditya-git]

The existing alias tests in test_dagbuilder.py inject operator_aliases directly into DagBuilder's default_config, which bypasses the propagation code in dagfactory.py. I missed that the two test files cover different layers. test_dagbuilder.py tests DagBuilder in isolation, while the DAGFactory-level behavior of reading aliases from defaults.yml and copying them into default_config needed a separate test in test_dagfactory.py. Added that now along with the Airflow 3 import path fix.

[pankajastro]

Could you please document this feature?

[pankajastro]

I think we add example covering both Airflow 2 and Airflow 3 you can find example https://github.com/astronomer/dag-factory/tree/main/dev/dags

[Aaditya-git]

Sure, let me take a look.

[Aaditya-git]

Thanks @pankajastro. Quick clarification on covering both Airflow 2 and Airflow 3 here: operator_aliases is an alias-to-path map, so a single alias name like BashOperator can only point to one operator_path. That means I can't bind the same alias to both airflow.operators.bash.BashOperator (AF2) and airflow.providers.standard.operators.bash.BashOperator (AF3) in one list.

Which approach would you prefer?

1. Keep the AF3 path active and show the AF2 path as an inline comment, or
2. Use distinct alias names (e.g. BashOperator for AF3, BashOperatorLegacy for AF2), or
3. Something else you had in mind?

Happy to go either way once I know your preference.

[pankajastro]

I mean we should add example yml in both Airflow3 and Airflow2 that would in CI as integration test

• https://github.com/astronomer/dag-factory/tree/main/dev/dags/airflow2
• https://github.com/astronomer/dag-factory/tree/main/dev/dags/airflow3