I just made some commits that allow us to run our test suite in a docker container. Think of it as a mini-travis.
What it does:
- Checks out the code at a specified commit
- Creates a database and redis instance, runs in background
a. DB is optimised for speed, disables fsync.
- Runs our specs
- Runs our js tests
This is powered by the rake docker:test task.
My focus for this work was usability. Anyone can run our test suite by typing:
docker run -it --rm samsaffron/discourse_test
You can specify a commit if you wish:
docker run -it --rm -e COMMIT_HASH=a3e3d34 samsaffron/discourse_test
The container definition is at: https://github.com/discourse/discourse_docker/blob/master/image/discourse_test/Dockerfile
On my local box I am able to spin up an environment and run all the tests in 3:45 - (5:30 on digital ocean)
It is particularly interesting cause its completely standalone and disposable. We spin up a pristine environment and dispose of it once testing is done.
Why not use travis?
We still use travis, we just need our tests a lot earlier, there is a huge difference for us between waiting 12:38 and under 4 minutes. Additionally travis may have queuing time that is beyond our control.
Once our build process takes care of stamping the tests-passed branch, we only pull in code that passed tests, docker internal deploy and smoke tests.
Why not use traditional testing?
Recently we have started seeing odd failures due to phantomjs segfaults, it is very hard to diagnose what about the test box that is causing it. Further more, our test box had the standard "duct tape" Ruby install, I wanted to have something that is trivial to upgrade (which I can do now by simply updating the base image).
Future work
