Metadata-Version: 2.1
Name: django_migrations_ci
Version: 0.0.1
Summary: Django migrations CI optimization
Home-page: https://github.com/iurisilvio/django-migrations-ci
Author: Iuri de Silvio
Author-email: iurisilvio@gmail.com
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: Operating System :: OS Independent
Classifier: Framework :: Django
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Description-Content-Type: text/markdown
License-File: LICENSE

# django-migrations-ci
Optimizations to run less migrations on CI

Django migrations are slow because of state recreation for every migration and other internal Django magic.

In the past, I tried to optimize that, but discovered it's a [running issue](https://code.djangoproject.com/ticket/29898).

## Assumptions

1. I want to run my migrations on CI. It is a sanity check, even if they are generated by Django in some cases.
1. I don't have to run migrations all the time. If migrations didn't change, I can reuse them.
1. The solutions probably are CI-specific and database-specific, but it is possible to write code for a generic workflow and snippets to support each CI.

## Idea

### Generate database state from migrations
GitLab CI (the one I have more experience, but I'm sure others have similar features) has caching based on versioned files.

I can cache database state, based on migrations files (and installed dependencies?).

When cache exists, load this database state (restore?) before your tests and run your tests without migrations.

When cache doesn't exist, run migrations and dump the final state for an SQL file.

Dump and restore are database-specific, but possible to handle all Django supported databases.


## Workflow

This is how the "run test" CI job should work.

```
restore djangomigrations.sql from CI cache

if djangomigrations.sql exists on cache:
  Restore djangomigrations.sql to test database
else:
  Setup test database
  Dump test database to djangomigrations.sql

Clone the test database to run threaded tests
save djangomigrations.sql to CI cache
```

## Cache example on GitHub

TODO #1, I never did it but I'm sure it is possible in some way. See #1

## Cache example on GitLab

Still have to abstract for all databases, but I expect something like that will work:

```
test_job:
  stage: test
  script:
    - |
      if [ -f djangomigrations-dbtest.sqlite3 ]; then
        cp djangomigrations-dbtest.sqlite3 dbtest.sqlite3
      else
        ./manage.py setup_test_db
        cp dbtest.sqlite3 djangomigrations-dbtest.sqlite3
      fi
    - ./manage.py clone_test_db
    - pytest -n $(nproc)
  cache:
    key:
      # GitLab docs say it accepts only two files, but for some reason it works with wildcards too.
      # You can't add more than two lines here.
      files:
        - "requirements.txt"
        - "*/migrations/*.py"
    paths:
      - djangomigrations-dbtest.sqlite3
 ```
