We are not using the limit flag in the actual run_pep8 method; removing
that from scripts. Operationally, pep8 has been enforcing a limit of
zero for awhile; this finishes that realization.
Also, all pep8 reports now appear under the reports/pep8 folder, rather than
per-system.
We've transitioned many lettuce tests to bok-choy. It no longer
makes sense to keep LMS acceptance in two shards (each taking less
than 5 mins to run the actual tests).
Bok choy will now be broken as follows:
* shard 1
* shard 2
* shard 3
* default shard (i.e. 'none of the above')
We use our shards to break up work and reduce overall test time by leveraging
multiple test systems.
When using -p, the underlying diff-quality command will pass that
number as a value for --fail-under.
For example,
paver run_quality -p 75
Will pass 75 into the --fail-under switch on diff-quality.
Also upgrades diff-cover in order to take advantage of this funcitonality.
This adds the -l switch, wherein a violations limit is passed in. For
example:
paver run_pep8 -l 700
Will fail if more than 700 violations are found.
By default, this limit is not enforced (i.e. if the -l switch
is not passed into the command, then a limit will not be put
into effect for that run)
This accomplishes three things:
1. Create a 3rd bok-choy shard
2. Allow the script to run 'all' shards
3. If the script receives an unknown shard, it will pass through empty tests.
The last one (3) is intended to allow us to expand to additional shards
on our Jenkins infrastructure. If we have, for example, a 4th shard introduced,
but someone attemps to run a commit that is older (and therefore still
has 3 shards); the script will just pass-through shard '4'. This means
older commits can still get tested. In that case, the older commit
will still test all cases, because the last shard (n) is basically an
'everything else' shard.
