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
In there currently as wsgi has the credstash which we don't won't to apply in non-awe environments. This will need a refactor to better handle code duplication.
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
