Using an arbitrary single test: vagrant ~/treeherder $ git status HEAD detached at 818c955 nothing to commit, working directory clean vagrant ~/treeherder $ time py.test tests/model/test_error_summary.py ... ============================================== 13 passed in 11.78 seconds ============================================== real 0m13.464s user 0m7.416s sys 0m0.676s Then after updating the repo from the host: vagrant ~/treeherder $ git status HEAD detached at 50a879f nothing to commit, working directory clean vagrant ~/treeherder $ time py.test tests/model/test_error_summary.py ... ============================================== 13 passed in 21.53 seconds ============================================== real 0m23.212s user 0m15.048s sys 0m0.764s vagrant ~/treeherder $ rm treeherder/perf/migrations/0002_auto_20151014_0922.py vagrant ~/treeherder $ time py.test tests/model/test_error_summary.py ... ============================================== 13 passed in 11.81 seconds ============================================== real 0m13.494s user 0m7.336s sys 0m0.752s -> The migration added by bug 1207648 doubles the Python test runtime both locally and also on Travis. eg compare: https://travis-ci.org/mozilla/treeherder/builds/85375469 https://travis-ci.org/mozilla/treeherder/builds/85595332 Guessing this is due to the issues with how the test DB is set up, for now I think we could just work around it by squashing the migrations files: https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations We'll probably want to wait until we've run the migrate after bug 1216153.
Hmm so I tried squashing the perf migrations and then deleting the old files as mentioned in the Django migrations docs, however the tests didn't speed up. I notice the squashed migration had a dependency on the 0002_... model migration file, unlike the old perf initial migration, so perhaps it's causing that migration to run anyway? If I delete all perf and all model migrations and then run a |manage.py makemigrations|, I can get the test runtime back to what it was before. Mauro, presuming migration has run on all of stage/prod/Heroku/our Vagrant instances, are there any disadvantages to just blowing away the existing migrations and starting from scratch with the initial migration file? I'm presuming the perf difference here is that we're currently using the skip initial migrations option, so get a perf win so long as they are all only initial migrations?
You will have to fake-migrate to the initial migration to do that. That will change the content of the django_migrations table and set 0001_initial for the app you want to reset.
Fixed by bug 1193836.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
No longer depends on: 1216153
Resolution: --- → DUPLICATE
Duplicate of bug: 1193836
You need to log in before you can comment on or make changes to this bug.