Check if someone else has already begun work on the change you have in mind in the issue tracker
- If not, create a ticket describing the change you're proposing in the issue tracker
- Check out the latest version of the source code
git clone http://git-wip-us.apache.org/repos/asf/cassandra.git cassandra-trunk
- 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
- 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)
- Attach the newly generated patch to the issue and click "Submit patch" in the left side of the JIRA page
- Wait for other developers or committers to review it and hopefully +1 the ticket
- 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.
Install ccm. You can do this with pip by running pip install ccm.
Install nosetests. With pip, this is pip install nose.
Clone the dtest repo: https://github.com/riptano/cassandra-dtest.git
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.
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
Run a basic coverage report of unit tests using ant codecoverage
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).
View the report at build/jacoco/index.html.
When done, clean up jacoco data so it doesn't confuse your next coverage report: ant jacoco-cleanup.
Jenkins runs the Cassandra tests continuously: http://cassci.datastax.com/ (Builders for stable branches also exist.)
- IntelliJ Project Settings:
Got commit access? Outstanding! Here are the conventions we follow.
Commit messages take the form of
<explanation> 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
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.