This refactors `parse_migration_status` to copy the algorithm of
Django's `showmigrations` command instead of parsing its output. This is
done so that the code is not susceptible to breaking changes if Django
modifies showmigrations's implementation.
The previous `parse_migration_status` logic has been repurposed into a
test utility function (`prase_showmigrations`). It is used to verify
that the new `parse_migration_status` generates output identical to the
actual `showmigrations` command.
The `test_clean_up_migration_status_json` is removed because
`test_parse_migration_status` has covered that behavior.
This commit adds `parse_migration_status`, which takes in the string
output of `showmigrations` and parse it into key-value pair of installed
apps and a list of its migration status.
This is a prep commit to rework the check migrations function of
import/export which will parse the output of `showmigrations` to write
the `migration_status.json` file.
This consolidates the list of stale migration to
`lib/migration_status.py` as `STALE_MIGRATIONS`.
This is a prep work to make the migration status tool at
`migration_status.py` be able to clean its output of these migrations
too.
in `get_migrations_status`, we clean up the printed output of any ANSI
codes used to format the output. Currently the regex only cleans up bold
ANSI escape code (\x1b[1m) and style reset code (\x1b[0m). So it won't
be able to clean up basic ANSI escape codes such as "\x1b\31;1m" which
is used to format `showmigrations` output for apps with no migrations.
e.g, "\x1b\31;1m (no migrations)"
This commit updates the regex to catch a wider range of basic ANSI
codes.
The `get_migration_status` command calls `connections.close_all()` when
its done and it was previously only called when we need to rebuild the
dev or test database and when running the `get_migration_status`
command.
This commit moves the `connections.close_all()` call out of the function
and into `test_fixtures.py` directly, making sure it will only be called
when we are rebuilding the dev/test database. This is a prep work to
refactor the check migration function of import/export later on which
plans to use `get_migration_status`.
This moves `get_migration_status` to its own file in
zerver/lib/migration_status.py. This is a prep work to refactor the
check migration function of import/export later on.
Some of the imports are moved into `get_migration_status` because we're
planning to share this file with `check-database-compatibility` which is
also called when one does `production-upgrade`, so we'd want to avoid
doing file-wide import on certain types of modules because it will fail
under that scenario.
In `test_fixtures.py`, `get_migration_status` is imported within
`Database.what_to_do_with_migrations` so that it is called after
`cov.start()` in `test-backend`. This is to avoid wierd interaction with
coverage, see more details in #33063.
Fixes#33063.
