Detect backward incompatible migrations for your django project. It will save you time by making sure migrations will not break anything.
pip install django-migration-linter
django-migration-linter DJANGO_PROJECT_FOLDER [GIT_COMMIT_ID] [--ignore-name-contains=IGNORE_NAME_CONTAINS] [--include-apps INCLUDE_APPS [INCLUDE_APPS ...] | --exclude-apps EXCLUDE_APPS [EXCLUDE_APPS ...]]
Parameter | Description |
---|---|
DJANGO_PROJECT_FOLDER |
An absolute or relative path to the django project. |
GIT_COMMIT_ID |
If specified, only migrations since this commit will be taken into account. If not specified, all migrations will be linted. |
--ignore-name-contains IGNORE_NAME_CONTAINS |
Ignore migrations containing this name. |
--ignore-name IGNORE_NAME [IGNORE_NAME ...] |
Ignore migrations with exactly one of these names. |
--include-apps INCLUDE_APPS [INCLUDE_APPS ...] |
Check only migrations that are in the specified django apps. |
--exclude-apps EXCLUDE_APPS [EXCLUDE_APPS ...] |
Ignore migrations that are in the specified django apps. |
--verbose or -v |
Print more information during execution. |
--database DATABASE |
Specify the database for which to generate the SQL. Defaults to default. |
--cache-path PATH |
specify a directory that should be used to store cache-files in. |
--no-cache |
Don't use a cache. |
3YOURMIND is running the linter on every build getting pushed through CI.
Checkout the examples/
folder to see how you could integrate the linter in your test suite.
The linter analyses your migrations and checks the SQL for:
- Added
NOT NULL
columns, which don't have a DEFAULT value - Dropping columns
- Renaming columns
- Renaming tables
- Altering columns (which can be backward compatible and eventually ignored)
Those are the most important and frequent backward incompatible migrations. We are happy to add more if you have some.
You can also ignore migrations by adding this to your migrations:
import django_migration_linter as linter # ... operations = [ linter.IgnoreMigration(), # ... ] # ...
By default, the linter uses a cache to prevent linting the same migration again.
The default location of the cache on Linux is
/home/<username>/.cache/django-migration-linter/<version>/<ldjango-project>.pickle
.
Since the linter uses hashes, modifying migration files, will re-run the linter on that migration.
If you want to run the linter without cache, use the flag --no-cache
.
If you want to invalidate the cache, delete the cache folder.
The easiest way to run the tests is to invoke tox.
First, thank you very much if you want to contribute to the project.
Please base your work on the master
branch and also target this branch in your pull request.
Keeping Django database migrations backward compatible
django-migration-linter is released under the Apache 2.0 License.