flask-script has been deprecated by the internal flask.cli module, but
making this carries a few changes with it
* you should add FLASK_APP=application.py and FLASK_DEBUG=1 to your
environment.sh.
* instead of using `python app.py runserver`, now you must run
`flask run -p 6012`. The -p command is important - the port must be
set before the config is loaded, so that it can live reload nicely.
(https://github.com/pallets/flask/issues/2113#issuecomment-268014481)
* find available commands by just running `flask`.
* run them using flask. eg `flask list_routes`
* define new tasks by giving them the decorator
`@app.cli.command('task-name')`. Task name isn't needed if it's just
the same as the function name. Alternatively, if app isn't available
in the current scope, you can invoke the decorator directly, as seen
in app/commands.py
Back on my old 2013 Macbook Pro, 2 was the optimum number of cores for the fastest test runs. Which is why I chose `-n2` when I originally introduced this flag (see 9ced677ec7).
Now I have a faster Macbook (same as every other developer), which has more cores to take advantage of.
We also use 4 cores when running the API tests.
Cores | Time taken to run tests
--- | ---
1 | 28.31s
2 | 18.15s
3 | 14.33s
4 | 12.32s
5 | 12.98s
6 | 13.49s
8 | 15.37s
previously in run_app_paas.sh, we captured stdout from the app and
piped that into the log file. However, this came up with a bunch of
problems, mainly that exceptions with stack traces often weren't
formatted properly, and kibana could not parse them
instead, with the updated utils library, we can use that to log json
straight to the appropriate directory directly.
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
