The actual report will continue to be piped into reports/python_complexity.log.

By exposing the paver output (approx 4 lines), we'll be able to consume
the actual complexity number in our logs and therefore trend the results
in our log aggregator.

Use the system version of firefox for running test.

This reverts commit 04f87694, reversing
changes made to 4b196d42.

Use the system version of firefox for running test.

- Handle case when no files are linted
- Skip deleted files for safe commit script
- Add verbose options for safe commit

- Add rule based thresholds
- Add safecommit to Jenkins

This is a backwards-compatible window for this upgrade. It will
later be replaced with using the default location (whatever's on
PATH)

This is a backwards-compatible window for this upgrade. It will
later be replaced with using the default location (whatever's on
PATH)

This also ensures that future lms shards are handled in a
smarter way, like our bok-choy shards. When no shard is
specified, rather than running all shards, only create
an empty xunit report.

This will leverage the nose attrib plugin to allow us
to break tests apart on our build system to run
in parallel on separate nodes.

This includes:
* Ability to specify number of processes to run bok-choy tests in
* A forked nose commit to get the multiprocess plugin's logging to work
* A different plugin (xunitmp) must be used for pulling together xunit results

This works by:
* Starting the various servers that are needed for the acceptance test environment
* Running the tests themselves in multiprocess mode

In the event of a pylint failure, we need to cat the log. This will also
ensure that the remaining scripts in the job can run.

The jenkins-common script is the better place for this particular setup, since that
script is doing similar setup steps to prepare the environment for running
various tests/subsequent scripts. This also will resolve downstream processes,
such as our jenkins AMI builder (for jenkins-worker images).

Note that because js testing occurs on a different CI job than python
unit testing, files will not be clobbered by this change. The python unit
testing job also creates the same-named report through the diff_coverage
task.

The platform includes jshint as a development tool, and our
builds are enforcing a limit on total number of jshint violations.
This commit will enforce no new jshint violations on a per-change
basis, much like pylint and pep8 are enforced. So with this change,
we'll be enforcing our linting requirements consistently, regardless
of type of violations.

Also on Jenkins, runs quality task after installing jshint.