Differences between revisions 62 and 63
Revision 62 as of 2015-03-24 06:27:30
Size: 5451
Editor: PhiloYang
Revision 63 as of 2015-11-25 16:09:53
Size: 5742
Editor: AdamHolmberg
Deletions are marked like this. Additions are marked like this.
Line 94: Line 94:
== Bundled Drivers ==
A copy of the Python driver is included for use in `cqlsh`. For instructions on how to package the bundled driver for the Cassandra project, see the [[https://github.com/datastax/python-driver/blob/master/README-dev.rst#packaging-for-cassandra|instructions here]].


  1. Pick an issue to work on. If you don't have a specific itch to scratch, some possibilities are marked with the low-hanging fruit label in JIRA.

  2. Read the relevant parts of ArchitectureInternals; watching http://www.youtube.com/watch?v=W6e8_IcgJM4 will probably also be useful

  3. Check if someone else has already begun work on the change you have in mind in the issue tracker

  4. If not, create a ticket describing the change you're proposing in the issue tracker
  5. Check out the latest version of the source code
  6. Modify the source to include the improvement/bugfix
    • Verify that you follow Cassandra's CodeStyle.

    • Verify that your change works by adding a unit test.
    • Make sure all tests pass by running "ant test" in the project directory.
      • You can run specific tests like so: ant test -Dtest.name=SSTableReaderTest`

    • For testing multi-node behavior, https://github.com/pcmanus/ccm is useful

  7. When you're happy with the result create a patch:
    • git add <any new or modified file>

    • git commit -m '<message>'

    • git format-patch
    • mv <patch-file> <branchname-issue.txt> (e.g. trunk-123.txt, cassandra-0.6-123.txt)

  8. Attach the newly generated patch to the issue and click "Submit patch" in the left side of the JIRA page
  9. Wait for other developers or committers to review it and hopefully +1 the ticket
  10. Wait for a committer to commit it.

Testing and Coverage

Setting up and running system tests:

Running the Unit Tests

Simply run ant test to run all unit tests. To run a specific test class, run ant -Dtest.name=<ClassName>. To run a specific test method, run ant testsome -Dtest.name=<ClassName> -Dtest.methods=<comma-separated list of method names>.

You can also run tests in parallel: ant test -Dtest.runners=4.

Running the dtests

The dtests use ccm to test a local cluster.

  1. Install ccm. You can do this with pip by running pip install ccm.

  2. Install nosetests. With pip, this is pip install nose.

  3. Install cassandra python driver. pip install cassandra-driver

  4. Clone the dtest repo: https://github.com/riptano/cassandra-dtest.git

  5. Set $CASSANDRA_DIR to the location of your cassandra checkout. For example: export CASSANDRA_DIR=/home/joe/cassandra. Make sure you've already built cassandra in this directory.

  6. Run all tests by running nosetests from the dtest checkout. You can run a specific module like so: nosetests cql_tests.py. You can run a specific test method like this: nosetests cql_tests.py:TestCQL.counters_test

Running the code coverage task

  1. Run a basic coverage report of unit tests using ant codecoverage

  2. Alternatively, run any test task with ant jacoco-run -Dtaskname=some_test_taskname. Run more test tasks in this fashion to push more coverage data onto the report in progress. Then manually build the report with ant jacoco-report (the 'codecoverage' task shown above does this automatically).

  3. View the report at build/jacoco/index.html.

  4. When done, clean up jacoco data so it doesn't confuse your next coverage report: ant jacoco-cleanup.

Continuous integration

Jenkins runs the Cassandra tests continuously: http://cassci.datastax.com/ (Builders for stable branches also exist.)



Got commit access? Outstanding! Here are the conventions we follow.

Commit messages take the form of


patch by <author>; reviewed by <committer> for CASSANDRA-<ticket>

When committing to multiple branches, start with the most-stable and merge forwards. For instance, if you had a fix to apply to 1.1, 1.2, and trunk, you would first commit to 1.1, and push changes. Then, switch to your 1.2 branch by doing

    git checkout cassandra-1.2
  • and run

    git merge cassandra-1.1

If there are conflicts, resolve them and commit, followed by a push. Finally, switch to trunk by doing

    git checkout trunk

and run

    git merge cassandra-1.2

again resolve conflicts if the exist, and commit and push.

See http://www.youtube.com/watch?v=AJ-CpGsCpM0 for an in-depth explanation of why fixes should be merged forwards from more-stable branches, rather than backported from trunk.

This workflow also makes it so git knows what commits have been made to earlier branches but not to trunk: if you forget to merge a fix immediately, the next time someone goes to merge from the branch, git will incorporate the forgotten ones too.

Bundled Drivers

A copy of the Python driver is included for use in cqlsh. For instructions on how to package the bundled driver for the Cassandra project, see the instructions here.


HowToContribute (last edited 2015-11-25 16:09:53 by AdamHolmberg)