andpp/mopidy
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add Travis CI description to development docs

Browse Source
This commit is contained in:
Stein Magnus Jodal 2012-09-05 23:58:30 +02:00
parent 1255b87877
commit 8b4302e388
1 changed files with 18 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
docs/development/contributing.rst
View File

@ -104,17 +104,26 @@ For more documentation on testing, check out the `nose documentation
<http://somethingaboutorange.com/mrl/projects/nose/>`_.
Continuous integration server
=============================
Continuous integration
======================
We run a continuous integration (CI) server at http://ci.mopidy.com/ that runs
all test on multiple platforms (Ubuntu, OS X, etc.) for every commit we push to
GitHub.
Mopidy uses the free service `Travis CI <http://travis-ci.org/#mopidy/mopidy>`_
for automatically running the test suite when code is pushed to GitHub. This
works both for the main Mopidy repo, but also for any forks. This way, any
contributions to Mopidy through GitHub will automatically be tested by Travis
CI, and the build status will be visible in the GitHub pull request interface,
making it easier to evaluate the quality of pull requests.
In addition to running tests, the CI server also gathers coverage statistics
and uses pylint to check for errors and possible improvements in our code. So,
if you're out of work, the code coverage and pylint data at the CI server
should give you a place to start.
In addition, we run a Jenkins CI server at http://ci.mopidy.com/ that runs all
test on multiple platforms (Ubuntu, OS X, x86, arm) for every commit we push to
the ``develop`` branch in the main Mopidy repo on GitHub. Thus, new code isn't
tested by Jenkins before it is merged into the ``develop`` branch, which is a
bit late, but good enough to get broad testing before new code is released.
In addition to running tests, the Jenkins CI server also gathers coverage
statistics and uses pylint to check for errors and possible improvements in our
code. So, if you're out of work, the code coverage and pylint data at the CI
server should give you a place to start.
Writing documentation