test: CI test for db migration scripts on changes

[bowenliang123]

Description

• adding DB migration test to CI jobs, to ensure db migration scripts are ready to apply, preventing issues like fix: workaround db migration error when adding custom_disclaimer column to recommended_apps #4518
• this test only triggers when code changes happen in api/migration/** path

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update, included: Dify Document
• Improvement, including but not limited to code refactoring, performance optimization, and UI/UX improvement
• Dependency upgrade

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• TODO

Suggested Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods
• optional I have made corresponding changes to the documentation
• optional I have added tests that prove my fix is effective or that my feature works
• optional New and existing unit tests pass locally with my changes

[bowenliang123]

cc @takatost @Yeuoly
This test is only triggered on demand by the code changes in specific paths. It costs approximately 2 minutes to run through.

[Yeuoly]

How does this test catch issues like #4518? From what I understand, the problem comes from old data. Some records don't have the custom_disclaimer column, and during migration, Postgres can't set the custom_disclaimer field to null because nullable is set to None. But this test only checks the migration process—it doesn't insert any data. It makes sure there won't be two branching paths, but it can't fix issues like #4518.

[takatost]

LGTM

[takatost]

How does this test catch issues like #4518? From what I understand, the problem comes from old data. Some records don't have the custom_disclaimer column, and during migration, Postgres can't set the custom_disclaimer field to null because nullable is set to None. But this test only checks the migration process—it doesn't insert any data. It makes sure there won't be two branching paths, but it can't fix issues like #4518.

Yeah, adding new fields without data and making them non-nullable will not cause any issues.
But this test can detect a part of issues.

[bowenliang123]

Agree. Thanks.