336f1f8c21
|
||
|---|---|---|
| .circleci | ||
| bin | ||
| docs | ||
| frontend | ||
| missioncontrol | ||
| requirements | ||
| tests | ||
| .coveragerc | ||
| .dockerignore | ||
| .env-dist | ||
| .eslintrc.js | ||
| .gitignore | ||
| .neutrinorc.js | ||
| .pyup.yml | ||
| Dockerfile | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| contribute.json | ||
| docker-compose.yml | ||
| fixtures_init.sql | ||
| manage.py | ||
| package.json | ||
| pytest.ini | ||
| sample.snappy.parquet | ||
| setup.cfg | ||
| setup.py | ||
| yarn.lock | ||
README.md
Mission Control
Mission Control is a monitoring service for Firefox release health, it allows you to view in (near) real time the rate of crashes and other quantitative measures of quality. It uses the dataset generated by the telemetry-streaming library.
The server-side backend is written in Python using Django. The UI is written in React, Redux and metricsgraphics.
Getting in touch
If you have any questions about Mission Control (either as a user or contributor), the best place to ask is the #missioncontrol channel on irc.mozilla.org (learn more about irc @ Mozilla).
Contributing
We welcome contributions to Mission Control! Working on the UI component (see instructions immediately below) does not require any special access to Mozilla's internal systems.
If you’re looking for a way to jump in and contribute, our list of good first issues is a great place to start.
Instructions for development (UI only)
If you only want to hack on the UI, you can set up a local-only of missioncontrol which pulls data from the current production server. You only need to have yarn installed.
Run:
yarn install
yarn start
This should start up a webserver at http://localhost:5000 which you can connect to.
To run the Jest tests for Mission Control's React components, execute:
yarn test
Instructions for development (full stack)
Make sure you have docker, docker-compose, and yarn installed.
Then run:
yarn install
cp .env-dist .env
make build
make up
make fixtures
After you have brought the environment up, you can bring up a development version of
the server by running make shell and then running ./manage.py runserver
from there. You should then be able to connect to http://localhost:8000 from
your web browser.
By default the environment uses a rather improverished set of test data, so
the environment will not be that interesting. If you have Mozilla credentials,
you can set up PRESTO_URL and SECRET_KEY variables in a .env file to have it pull data
from a production dataset. Once you have that set up, you should be able to
download a set of recent data from a shell environment (make shell) via the
load_measure_data subcommand. E.g.:
./manage.py load_measure_data linux release main_crashes
The recommended way of running the tests locally is via the shell environment.
After running make shell, execute:
pytest tests/
By default all tests and linters are run. Often you just want to run a subset of the python tests. You can do this by adding some arguments to your tox invocation:
tox -e tests -- -k tests/test_api.py # run only tests in test_api.py
Instructions for deployment
The target environment for this project follows the dockerflow conventions. In order to run it correctly, a number of environment variables need to be set up. The full list of variables can be found in the web section of the docker-compose.yml file. From a services standpoint, this project requires:
- a Postgres DB to store the application data, defined by DATABASE_URL
- a Presto/Athena service, defined by PRESTO_URL
- an optional Redis cache service, defined by CACHE_URL