Validate on real Airflow¶

Static rules cannot see values that only exist at render or run time, such as Jinja-injected schedules or DAG(**config). Validation closes that gap: dagshift loads your DAG folder with Airflow's own DagBag, in a Python environment that has the target Airflow installed, and reports import errors and deprecation warnings in the Problems panel.

1. Create an environment with the target Airflow¶

Use the constraints file that matches the Airflow and Python versions:

Airflow 3.3Airflow 2.11Windows

python -m venv ~/.venvs/airflow3
~/.venvs/airflow3/bin/pip install "apache-airflow==3.3.1" \
  --constraint https://raw.githubusercontent.com/apache/airflow/constraints-3.3.1/constraints-3.12.txt

python -m venv ~/.venvs/airflow2
~/.venvs/airflow2/bin/pip install "apache-airflow==2.11.0" \
  --constraint https://raw.githubusercontent.com/apache/airflow/constraints-2.11.0/constraints-3.12.txt

Airflow does not run natively on Windows. Create the environment in WSL and set dagshift.validate.airflowPython to its interpreter, or open the project in WSL with the WSL extension and use the Linux path.

Add any providers your DAGs import (for example apache-airflow-providers-google) to the same environment.

2. Point dagshift at it¶

Run dagshift: Validate DAGs on Target Airflow.... The first time, it asks for the Python interpreter and the DAG folder. They are saved in:

Setting	Example
`dagshift.validate.airflowPython`	`~/.venvs/airflow3/bin/python`
`dagshift.validate.dagFolder`	`dags`
`dagshift.validate.pythonPath`	`["."]`, extra import roots for your DAG files

Validate the upgraded copy if you wrote one, or the workspace after editing in place.

DAG factories that render at build time¶

If your DAG files are generated by a script, set dagshift.validate.renderCommand, for example:

PYTHONPATH=. python framework/dag_builder.py

It runs in a temporary copy of the DAG folder's parent, never in your workspace, and validation then loads the rendered output.

Validation runs your DAG files

Loading DAGs executes their top-level code, as Airflow does. In Restricted Mode validation is disabled and workspace-level interpreter settings are ignored.

Airflow 3.0

On Airflow 3.0, validation parses in-process, so top-level airflow.sdk.Variable.get calls fail there even though a real DAG processor handles them. The report says so.