Currently the first time you run the server you need to manually
syncdb, create superuser and collect assets. Do this automatically
on container launch
This caused inaccurate timings and some duplicate jobs running. There
should only ever be a single beat service, whereas we were using a dev
feature to run a beat service on all 16 workers
django-compressor 1.4 does not support well Django 1.8,
and the `manage.py compress` was failing with
`ImportError: cannot import name template_source_loaders`
We cannot go above 1.5, as starting with 1.6, the unit test
`test_query` in `test_urlprefix.URLPrefixTestCase` fails with
'''
UncompressableFileError: '/test/static/bootstrap/css/bootstrap.css'
isn't accessible via COMPRESS_URL ('/static/') and can't be compressed
'''
alert.update_alert_plugins() is executed when the module is loaded.
During tests the module is loaded before the test database is created
causing problems. I've changed it to the intented affect of refreshing
on View initialisation
Main changes are to migrations. I started them again from scratch and
then renamed check to status_check (as check is now reserved by django).
The plugins also needed updating to be django 1.7 compatible. (they have
to defined their own migrations if they depend on an app with migrations
now)
We decided to start versioning at 0.6 to match the django version.
There isn't much reason for this beyond that the next 2 changes will
be django upgrades which will bump the version to 0.7 and 0.8
Add libffi-dev and libssl-dev to provision packages in order to overcome
version incompatibilities preventing 'vagrant up' from completing successfully
- Split out requirements in two files
(testing and main)
- Add Bash script running test with coverage
- Add .coveragerc configuration file,
including Django coverage plugin
- Add post-build to Travis script running CodeCov
- Add tox file for linting of:
- bash config files
- flake8
- Mute all flake8 violations currently not passing
- Install and run tox as part of Travis build
(inside one run because build matrix is hard)
The base test class `LocalTestCase` will setup base objects for all tests to use but because this is called for each test the IDs of the objects will change between tests. One of the child test classes `TestAPI` has a some static data used to check the response of API calls, however these IDs were hard coded meaning that if the order of the tests changed for any reason the test would fail. To fix this the IDs of the static data have been replaced with the object ID meaning they will always be correct.
Adding a new field for linkable recovery instructions, i.e. a link to a
runbook on the company's wiki.
A few notes/things to point out in this change:
* I expanded form field widths on the service and instance pages...
I had to add a new field and it was really small by default, so I made
all the widths match because I think it looks better.
* The InstanceForm class had hackpad_id defined as a field, but not as a
widget, so it wasn't visiable. I think that was a mistake, so I
cleaned it up. For most users I don't think it make sense to have
documentation for particular instances, so removing it seems like the
right thing to do.
Closes#273
We experienced problems on certain StatusChecks that had a moderate number of StatusCheckResults that had problems looking up the latest check when updating. This lead to high load on the database and the app not being able to update checks correctly. Having an index on the exact lookup of `last_result` removes this problem.
