hi sergey: took much longer than i hoped but i have a patch up for review to hopefully improve the dtest user experience.
https://issues.apache.org/jira/browse/CASSANDRA-14134 i sent an email summarizing it earlier this morning in a separate thread. i moved all the undocumented environment variables to command line arguments and added help strings for all of them. there is now some very basic environmental validation that happens up front: either —cassandra-dir or —cassandra-version are required command line arguments. if you invoke with —help i even added a note that “ant clean jar” is required to be run before hand on the cassandra dir —cassandra-dir is pointed at. in addition: -if you’re running on mac i check that the required loopback interfaces have been created (if not print an error message with the command to run and create the other loopback interfaces). -upgrade tests aren’t invoked/collected by default -for tests marked with the “resource_intensive” annotation (these tests tend to invoke ccm by populating the test cluster with 9 instances requiring a good chunk of ram). instead of making the user know if they should run these or not i do a quick check at runtime to determine the amount of ram available on the system and dynamically enable or disable the resource_intensive annotated tests! (there are command line arguments of course to explicitly override this behavior if required for some reason). -i added a bunch of extra documentation to README.md with the hope that it’s the first thing people see on GitHub and more likely to be read (how to start the tests, bootstrap and setup the required dependencies, and some tips on debugging tests) curious on your thoughts from a user perspective of how a these improvements will help someone like yourself who recently tried to test your patch against the dtests? any other areas i didn’t address yet that would make getting bootstrapped better? hopefully we can shortly get a updated and greatly enhanced circleci 2.0 yaml in the upstream repo that reliably will let even the most casual contributor make a change and run the unit and dtests against their branch in circleci (using just a free circleci OSS account) without any end user effort! best, kjellman On Dec 13, 2017, at 12:28 PM, Michael Kjellman <mkjell...@internalcircle.com<mailto:mkjell...@internalcircle.com>> wrote: i’ve been working on a story to improve this around the clock. including better documentation (and a —help flag with options to make it easy to know how to run dtests and a few runtime sanity checks about the environment)! stay tuned! On Dec 13, 2017, at 3:24 AM, Sergey <cassandra.bu...@gmail.com<mailto:cassandra.bu...@gmail.com>> wrote: Hi! I am looking for a way to test the patch I made to specific version of Cassandra (3.0.15) by leveraging the dtest. Documentation for the dtests says: “The only thing the framework needs to know is the location of the (compiled) sources for Cassandra. There are two options: Use existing sources: CASSANDRA_DIR=~/path/to/cassandra nosetests” So if I git clone the Cassandra sources to ~/path/to/Cassandra, switch to tag 3.0.15, apply my patch and run ant – will this be enough for my purpose? Best regards, Sergey
