Integrate alembic check in ci

[guan404ming]

Related Issue

closes #48998
cc: @ashb

Why

Since Alembic 1.9, a built-in command alembic check is available to checks if there are pending upgrade operations in the migration file, to integrating this check into our CI ensures that no model changes go unnoticed, preventing potential issues that could arise when applying migrations in production.

How

• add a new step to the ci

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[ashb]

Could you add a change to a model in a second commit on this PR (that we will shortly revert/undo) to test that this fails as expected please?

[guan404ming]

Sure! I would do it later after this CI finished (make sure it could pass now)

[ashb]

Oh, I'm not sure we want this in here though actually.

The airflow db is designed for end users/Airflow administrators to run, but the check command is only useful for Airflow devs

[guan404ming]

Thanks for reviewing, I would remove it from airflow db ~

[ephraimbuddy]

alembic check does not check if there's a difference between ORM models and migration files as you described. It only checks if there are pending upgrade operations in the migration file. For example, if you upgraded to Airflow 3.0 and your database migration head is still at Airflow 2.7.0. Running alembic check will detect that you have not upgraded your database to Airflow 3.0. As Ash suggested, you can add a field to a model and let us see that the CI fails due to the alembic check detecting the added field.

[guan404ming]

Thanks for pointing out. I would modify my PR summary later.
I’ve also tried multiple times about the suggestion from Ash. But I can’t see the ci fail because of alembic check after I delete or add field. I’m not really sure the root cause about it but I could try it again. Then we could see the result. Thanks a lots.

[guan404ming]

I've added a field named test in dag and tried locally with breeze shell which work well to detect the change.

$ breeze shell "cd airflow-core/src/airflow && alembic check"

[2025-05-06T12:23:10.917+0000] {migration.py:207} INFO - Context impl SQLiteImpl.
[2025-05-06T12:23:10.919+0000] {migration.py:210} INFO - Will assume non-transactional DDL.
[2025-05-06T12:23:11.124+0000] {compare.py:400} INFO - Detected added column 'dag.test_field'
[2025-05-06T12:23:11.158+0000] {messaging.py:71} ERROR - New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000), table=<dag>))]
  FAILED: New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000),
  table=<dag>))]
Error 255 returned

but

$ pre-commit run check-model-changes
Check if model changes require DB migration..............................Passed

[ephraimbuddy]

I've added a field named test in dag and tried locally with breeze shell which work well to detect the change.

$ breeze shell "cd airflow-core/src/airflow && alembic check"

[2025-05-06T12:23:10.917+0000] {migration.py:207} INFO - Context impl SQLiteImpl.
[2025-05-06T12:23:10.919+0000] {migration.py:210} INFO - Will assume non-transactional DDL.
[2025-05-06T12:23:11.124+0000] {compare.py:400} INFO - Detected added column 'dag.test_field'
[2025-05-06T12:23:11.158+0000] {messaging.py:71} ERROR - New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000), table=<dag>))]
  FAILED: New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000),
  table=<dag>))]
Error 255 returned

but

$ pre-commit run check-model-changes
Check if model changes require DB migration..............................Passed

wow. That's nice

[ephraimbuddy]

Did you check if we can have this as a test in utils/test_db.py

[guan404ming]

It works as well in my local computer. Let me test it on ci
Thanks for the suggestion.

[ephraimbuddy]

There's a bug in CI that might be causing all these to pass: https://github.com/apache/airflow/actions/runs/14898553456/job/41845929327?pr=49002#step:5:5931
I'm working on it

[guan404ming]

Thanks a lots!

[guan404ming]

Rebased and hope ci failed!

[ephraimbuddy]

So, the bug I fixed is unrelated. I think I understand what's happening. The DB is initialized from the ORM, and we try to run the file migration, too, by running downgrade and upgrade commands. In the end, the new field you added is already in the DB. When the alembic check command is run, the database already has the new field, and therefore, it's not detected.

In airflow 2, we could easily detect this new field because our tests initializes the database from the migration files instead of the ORM.

[guan404ming]

Yes, I think that is unrelated. What you said is match with my local experiment. It would only successfully detect the error when I init with right ORM and then try add/delete something. I still try to figure how to deal with this without breaking the whole initialization process.

[guan404ming]

Close now and would come back if I have better idea about this.