12b53e108a
The __future__ module [1] was used in this context to ensure compatibility between python 2 and python 3. We previously dropped the support of python 2.7 [2] and now we only support python 3 so we don't need to continue to use this module and the imports listed below. Imports commonly used and their related PEPs: - `division` is related to PEP 238 [3] - `print_function` is related to PEP 3105 [4] - `unicode_literals` is related to PEP 3112 [5] - `with_statement` is related to PEP 343 [6] - `absolute_import` is related to PEP 328 [7] [1] https://docs.python.org/3/library/__future__.html [2] https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html [3] https://www.python.org/dev/peps/pep-0238 [4] https://www.python.org/dev/peps/pep-3105 [5] https://www.python.org/dev/peps/pep-3112 [6] https://www.python.org/dev/peps/pep-0343 [7] https://www.python.org/dev/peps/pep-0328 Change-Id: I46f1872407495af231e65cfe784cee731b345f3b |
||
|---|---|---|
| coverage2sql | ||
| doc | ||
| etc | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| babel.cfg | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
Team and repository tags
coverage2sql README
Command to Read a coverage file and put the data in a SQL database
coverage2sql is a tool for storing data of test coverage into a SQL database. With using this tool, you can store time series coverage data and analyze it if your coverage rate is down.
- Free software: Apache license
- Documentation: https://docs.openstack.org/coverage2sql/latest/
- Source: https://opendev.org/openstack/coverage2sql
- Bugs: https://bugs.launchpad.net/coverage2sql
- Release notes: https://docs.openstack.org/releasenotes/coverage2sql
Usage
DB Setup
The usage of coverage2sql is split into 2 stages. First you need to prepare a database with the proper schema; coverage2sql-db-manage should be used to do this. The utility requires db connection info which can be specified with a config file. Obviously the sql connector type, user, password, address, and database name should be specific to your environment. coverage2sql-db-manage will use alembic to setup the db schema. You can run the db migrations with a config file:
coverage2sql-db-manage --config-file etc/coverage2sql.conf upgrade headThis will bring the DB schema up to the latest version for coverage2sql.
coverage2sql
Once you have a database setup with the proper database schema you can then use the coverage2sql command to populate the database with data from your test coverage file. coverage2sql takes in a .coverage file through by passing it file paths as positional arguments to the script at this moment.
For example:
coverage2sql --config-file etc/coverage2sql.conf coverage2sql .coverageThere are several options for running coverage2sql, they can be listed with:
coverage2sql --helpThe only required option is --database-connection. The
options can either be used on the CLI, or put in a config file. If a
config file is used you need to specify the location on the CLI.
TODO
To see the TODO, go to the launchpad site:
ChangeLog
To see the release notes go here: https://docs.openstack.org/releasenotes/coverage2sql/