759c42b10c
This commit updates the language in the Python PTI to be much more specific about how projects should be running tests. This is done so we can have a consistent experience between projects when running tests. The current state of affairs is far from ideal in that there are about 7 different ways projects run python unit tests. (some don't even comply with the looser previous PTI) For example:: * PBR's testr entrpoint "python setup.py test" https://github.com/openstack-dev/pbr/blob/master/pbr/testr_command.py * testr's setup tools entrypoint "python setup.py testr" https://github.com/testing-cabal/testrepository/blob/master/testrepository/setuptools_command.py * pretty_tox.sh wrapper scripts and variants (this was cargo culted from tempest and diverged significantly between each projects' forks) * ostestr (which is part of the os-testr package, but it's not the only thing there) * nosetests (the horizon case for django testing will likely be a continued exception) * proboscis (which are just the examples I know of off the top of my head) For anyone trying to work in multiple projects navigating this can be quite tricky, especially when trying to debug a failure. To clean this up, this patch defines one way to run python tests. Besides making the wording more explicit and providing specifics this commit also tries to provide some additional background information on why we use stestr. It's not always obvious the advantages it provides us, so this attempts to document it at a high level for the ages. Change-Id: I2637dd714cbb6d38ef8b8dc1083e359207118284 |
||
|---|---|---|
| doc/source | ||
| goals | ||
| pre-history | ||
| reference | ||
| resolutions | ||
| tools | ||
| .gitignore | ||
| .gitreview | ||
| .yamllint | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
This repository contains OpenStack Technical Committee reference documents and tracks official resolutions voted by the committee.
Directory structure:
- reference/
Reference documents which need to be revised over time. Some motions will just directly result in reference doc changes.
- resolutions/
When the motion does not result in a change in a reference doc, it can be expressed as a resolution. Those must be named YYYYMMDD-short-name with YYYYMMDD being the proposal date in order to allow basic sorting.
- goals/
Documentation for OpenStack community-wide goals, organized by release cycle. These pages will be updated with project status info over time, and if goals are revised.
See https://wiki.openstack.org/wiki/Governance/TechnicalCommittee for details.