Previously we used AWS which meant that we could create wheels
from our requirements and then install them offline which made
deployments quicker.
We're no longer using AWS so let's remove that.
Although CloudFoundry supports installing dependencies in an offline
environment as documented here:
http://docs.cloudfoundry.org/buildpacks/python/#vendoring
To achieve this we create a vendor/ directory which will contain
the packages to install. This uses --no-index and --find-links so will
not resolve for any dependencies from pypi. For this reason there is
assumed confidence that the vendor/ directory will contain all
of the dependencies we need.
PEP8 was renamed to pycodestyle; this issue explains why:
PyCQA/pycodestyle#466
This commit changes our tests to use pycodestyle instead of pep8.
No changes to our code were required as a result.
This file needs to exist before the app can run, so create it automatically
rather than including it as an extra setup step in the README. The API app
already does this.
We can make the tests run slightly faster by parallelizing them across
multiple CPU cores:
- from some casual testing locally, 2 cores gives the optimum speedup
- Travis container-based builds have 2 CPU cores available[1]
- the net gain is about 20%, or 2 seconds
- unfortunately we can’t do this on the API because each test is still
using the same instance of the database
1. https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments
- no config overrides - now all set in environment
- use different files for staging and live too allow for differently named env variables
- updates to run_app and run_tests scripts to set correct environment (test/development) so correct config picked up
- use environment file on deployed environments to pick correct config
Now you don’t need to remember what the two commands are and when you need to
run them, you can just run the bootstrap script instead.
Makes sense to have them here since the `pip install` is also in here.
Similar to how PEP8 enforces Python style, there are tools for front end code:
- jshint[1] for Javascript
- sass-lint[2] for SASS
This commit adds the Gulp plugins for both, and sets up some sensible rules
(which can be iterated on).
It also adds a command to `./scripts/run_tests.sh`, so that any errors in the
front end code will fail the build before it has a chance to be deployed.
1. http://jshint.com/
2. https://www.npmjs.com/package/sass-lint
