Previously, we restricted this to gunicorn to get it working on aur-dev.
This change makes it usable through any backend, and also no-op if
PROMETHEUS_MULTIPROC_DIR is not defined.
Signed-off-by: Kevin Morris <kevr@0cost.org>
In some cases, when tests fail through Docker, the database
ends up in an invalid state. This causes subsequent runs to
error out with non-sensical DB errors. The `test_initdb.py`
test suite runs tests which setup every modifiable table
in the database, so let's just run it first here to avoid
any invalid test DB state.
Signed-off-by: Kevin Morris <kevr@0cost.org>
This commit adds a new Arch dependency: `libeatmydata`, which
provides the `eatmydata` executable that stubs out fsync() operations.
We use `eatmydata` to run our sharness and pytests in Docker now.
With `autocommit=True`, required by SQLAlchemy to keep the
session up to date with external DB modifications, many fsync
calls are used in the SQLite backend; especially because we're wiping
and creating records in every DB-bound test.
**Before:**
- mysql: 1m42s (elapsed during pytest run)
- sqlite: 3m06s (elapsed during pytest run)
**After:**
- mysql: 1m40s (elapsed during pytest run)
- sqlite: 1m50s (elapsed during pytest run)
Shout out to @klausenbusk, who suggested this as a possible fix,
and it was. Thanks, Kristian!
Closes#120
Signed-off-by: Kevin Morris <kevr@0cost.org>
Instead of using Dockerfile for everything, we've introduced
a docker-compose.yml file and kept the Dockerfile to producing
a pure base image for the services defined.
docker-compose services:
- `mariadb` - Setup mariadb
- `sharness` - Run sharness suites
- `pytest-mysql` - Run pytest suites with MariaDB
- `pytest-sqlite` - Run pytest suites with SQLite
- `test` - Run all tests and produce a collective coverage report
- This target mounts a cache volume and copies any successful
coverage report back to `./cache/.coverage`. Users can run
`./util/fix-coverage ./cache/.coverage` to rewrite source
code paths and move coverage into place to view reports
on your local system.
== Get Started ==
Build `aurweb:latest`.
$ docker build -t aurweb:latest .
Run all tests via `docker-compose`.
$ docker-compose up test
You can also purely run `pytest` in SQLite or MariaDB modes.
$ docker-compose up pytest-sqlite
$ docker-compose up pytest-mysql
Or `sharness` alone, which only uses SQLite internally.
$ docker-compose up sharness
After running tests, coverage reports are stored in `./cache/.coverage`.
This database was most likely created in a different path, and so it
needs to be sanitized with `./util/fix-coverage`.
$ ./util/fix-coverage cache/.coverage
Copied coverage db to /path/to/aurweb/.coverage.
$ coverage report
...
$ coverage html
$ coverage xml
...
Defined components:
**Entrypoints**
- mariadb-entrypoint.sh - setup mariadb and run its daemon
- test-mysql-entrypoint.sh - setup mysql configurations
- test-sqlite-entrypoint.sh - setup sqlite configurations
- tests-entrypoint.sh - setup mysql and sqlite configurations
**Scripts**
- run-mariadb.sh - setup databases
- run-pytests.sh - run pytest suites
- run-sharness.sh - run sharness suites
- run-tests.sh - run both pytests and sharness
**Health**
- mariadb.sh - A healthcheck script for the mariadb service
- pytest.sh - A healthcheck script for the pytest-* services
- sharness.sh - A healthcheck script for the sharness service
This Docker configuration is setup for tests, but should be
extendable for web and git servers.
**Changes to Makefile**
- Remove `.coverage` in the `clean` target
- Add a `coverage` target which prints a report and outputs xml
Signed-off-by: Kevin Morris <kevr@0cost.org>
