You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
depot_tools/testing_support/coverage_utils.py

71 lines
2.2 KiB
Python

Add git-number script to calculate generation numbers for commits. Compatible with any git topology (multiple roots, weird branching/merging, etc.) I can't get it to be any faster (in python). Suggestions welcome :). On z600/linux, this takes 5.1s to calculate the initial count for 2e3de954ef0a (HEAD on src.git at the time of writing). Subsequent lookups take ~0.06s. For reference, this machine takes 3s to just list the revisions in sorted order without any additional processing (using rev-list). All calculations are stored in a git-notes-style ref with the exception that the leaf 'tree' object which would normally be stored in a git-notes world is replaced with a packed binary file which consists of records [hash int]. Each run of this script will create only 1 commit object on this internal ref which will have as its parents: * The previous git number commit * All of the target commits we calculated numbers for. This ref is then excluded on subsequent invocations of rev-list, which means that git-number will only ever process commit objects which it hasn't already calculated a value for. It also prevents you from attempting to number this special ref :). This implementation only has a 1-byte fanout which seems to be the best performance for the repos we're dealing with (i.e. on the order of 500k commit objects). Bumping this up to a 2-byte fanout became extremely slow (I suspect the internal caching structures I'm using are not efficient in this mode and could be improved). Using no fanout is slower than the 1 byte fanout for lookups by about 30%. R=agable@chromium.org, stip@chromium.org, szager@chromium.org BUG=280154,309692,skia:1639 Review URL: https://codereview.chromium.org/26109002 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@236035 0039d316-1c4b-4281-b951-d872f2087c98
11 years ago
# Copyright 2013 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
import distutils.version
import os
import sys
import textwrap
import unittest
ROOT_PATH = os.path.abspath(os.path.join(
os.path.dirname(os.path.dirname(__file__))))
def native_error(msg, version):
print textwrap.dedent("""\
ERROR: Native python-coverage (version: %s) is required to be
installed on your PYTHONPATH to run this test. Recommendation:
sudo apt-get install pip
sudo pip install --upgrade coverage
Add git-number script to calculate generation numbers for commits. Compatible with any git topology (multiple roots, weird branching/merging, etc.) I can't get it to be any faster (in python). Suggestions welcome :). On z600/linux, this takes 5.1s to calculate the initial count for 2e3de954ef0a (HEAD on src.git at the time of writing). Subsequent lookups take ~0.06s. For reference, this machine takes 3s to just list the revisions in sorted order without any additional processing (using rev-list). All calculations are stored in a git-notes-style ref with the exception that the leaf 'tree' object which would normally be stored in a git-notes world is replaced with a packed binary file which consists of records [hash int]. Each run of this script will create only 1 commit object on this internal ref which will have as its parents: * The previous git number commit * All of the target commits we calculated numbers for. This ref is then excluded on subsequent invocations of rev-list, which means that git-number will only ever process commit objects which it hasn't already calculated a value for. It also prevents you from attempting to number this special ref :). This implementation only has a 1-byte fanout which seems to be the best performance for the repos we're dealing with (i.e. on the order of 500k commit objects). Bumping this up to a 2-byte fanout became extremely slow (I suspect the internal caching structures I'm using are not efficient in this mode and could be improved). Using no fanout is slower than the 1 byte fanout for lookups by about 30%. R=agable@chromium.org, stip@chromium.org, szager@chromium.org BUG=280154,309692,skia:1639 Review URL: https://codereview.chromium.org/26109002 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@236035 0039d316-1c4b-4281-b951-d872f2087c98
11 years ago
%s""") % (version, msg)
sys.exit(1)
def covered_main(includes, require_native=None):
"""Equivalent of unittest.main(), except that it gathers coverage data, and
asserts if the test is not at 100% coverage.
Args:
includes (list(str) or str) - List of paths to include in coverage report.
May also be a single path instead of a list.
require_native (str) - If non-None, will require that
at least |require_native| version of coverage is installed on the
system with CTracer.
"""
try:
import coverage
if require_native is not None:
got_ver = coverage.__version__
if not getattr(coverage.collector, 'CTracer', None):
Add git-number script to calculate generation numbers for commits. Compatible with any git topology (multiple roots, weird branching/merging, etc.) I can't get it to be any faster (in python). Suggestions welcome :). On z600/linux, this takes 5.1s to calculate the initial count for 2e3de954ef0a (HEAD on src.git at the time of writing). Subsequent lookups take ~0.06s. For reference, this machine takes 3s to just list the revisions in sorted order without any additional processing (using rev-list). All calculations are stored in a git-notes-style ref with the exception that the leaf 'tree' object which would normally be stored in a git-notes world is replaced with a packed binary file which consists of records [hash int]. Each run of this script will create only 1 commit object on this internal ref which will have as its parents: * The previous git number commit * All of the target commits we calculated numbers for. This ref is then excluded on subsequent invocations of rev-list, which means that git-number will only ever process commit objects which it hasn't already calculated a value for. It also prevents you from attempting to number this special ref :). This implementation only has a 1-byte fanout which seems to be the best performance for the repos we're dealing with (i.e. on the order of 500k commit objects). Bumping this up to a 2-byte fanout became extremely slow (I suspect the internal caching structures I'm using are not efficient in this mode and could be improved). Using no fanout is slower than the 1 byte fanout for lookups by about 30%. R=agable@chromium.org, stip@chromium.org, szager@chromium.org BUG=280154,309692,skia:1639 Review URL: https://codereview.chromium.org/26109002 git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@236035 0039d316-1c4b-4281-b951-d872f2087c98
11 years ago
native_error((
"Native python-coverage module required.\n"
"Pure-python implementation (version: %s) found: %s"
) % (got_ver, coverage), require_native)
if got_ver < distutils.version.LooseVersion(require_native):
native_error("Wrong version (%s) found: %s" % (got_ver, coverage),
require_native)
except ImportError:
if require_native is None:
sys.path.insert(0, os.path.join(ROOT_PATH, 'third_party'))
import coverage
else:
print ("ERROR: python-coverage (%s) is required to be installed on your "
"PYTHONPATH to run this test." % require_native)
sys.exit(1)
COVERAGE = coverage.coverage(include=includes)
COVERAGE.start()
retcode = 0
try:
unittest.main()
except SystemExit as e:
retcode = e.code or retcode
COVERAGE.stop()
if COVERAGE.report() != 100.0:
print 'FATAL: not at 100% coverage.'
retcode = 2
return retcode