5df748b2ed
During development of a new git commit, locally running a whole unit
or functional test suite to check every minor code change is
prohibitively expensive. For maximum developer productivity and
happiness, it's generally desirable to make the feedback loop of the
traditional red/green cycle as quick as possible.
So add run-tests-for-diff.sh and run-tests.py to the tools/
subdirectory, using a few tricks as explained below to help with this.
run-tests.py takes a list of files on STDIN, filters the list for
tests which can be run in the current tox virtualenv, and then runs
them with the correct stestr options.
run-tests-for-diff.sh is a simple wrapper around run-tests.py which
determines which tests to run using output from "git diff". This
allows running only the test files changed/added in the working tree:
tools/run-tests-for-diff.sh
or by a single commit:
tools/run-tests-for-diff.sh mybranch^!
or a range of commits, e.g. a branch containing a whole patch series
for a blueprint:
tools/run-tests-for-diff.sh gerrit/master..bp/my-blueprint
It supports the same "-HEAD" invocation syntax as flake8wrap.sh (as
used by the "fast8" tox environment):
tools/run-tests-for-diff.sh -HEAD
run-tests.py uses two tricks to make test runs as quick as possible:
1. It's (already) possible to speed up running of tests by
source'ing the "activate" file for the desired tox virtualenv,
e.g.
source .tox/py36/bin/activate
and then running stestr directly. This saves a few seconds by
skipping the overhead introduced by running tox.
2. When only one test file needs to be run, specifying the -n option
to stestr will skip the costly test discovery phase, saving
several more valuable seconds.
Future commits could build on top of this work, harnessing a framework
such as watchdog / watchmedo[0] or Guard[1] in order to automatically
run relevant tests every time your editor saves changes to a .py file.
[0] https://github.com/gorakhargosh/watchdog - Python-based
[1] https://guardgem.org - probably best in class, but Ruby-based so
maybe unacceptable for use within Nova.
Change-Id: I9a9bda5d29bbb8d8d77f769cd1abf7c42a18c36b
|
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| playbooks | ||
| releasenotes | ||
| roles/run-post-test-hook | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| lower-constraints.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
OpenStack Nova
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, XenServer, OpenStack Ironic and PowerVM.
Use the following resources to learn more.
API
To learn how to use Nova's API, consult the documentation available online at:
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests.
Further developer focused documentation is available at:
Other Information
During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at: