tolbertam commented on code in PR #2041:
URL:
https://github.com/apache/cassandra-java-driver/pull/2041#discussion_r2975529937
##########
CONTRIBUTING.md:
##########
@@ -371,164 +493,11 @@ public TestRule chain =
RuleChain.outerRule(ccmRule).around(sessionRule);
Only use this for:
-* CCM tests that use `@CassandraRequirement` or `@DseRequirement` restrictions
at the method level
+* CCM tests that use `@BackendRequirement` restrictions at the method level
(ex: `BatchStatementIT`).
* tests where you *really* need to restart from a clean state for every method.
##### Mixed
It's also possible to use a `@ClassRule` for CCM / Simulacron, and a `@Rule`
for the session rule.
In that case, you don't need to use a rule chain.
-
-## Running the tests
-
-### Unit tests
-
- mvn clean test
-
-This currently takes about 30 seconds. The goal is to keep it within a couple
of minutes (it runs
-for each commit if you enable the pre-commit hook -- see below).
-
-### Integration tests
-
- mvn clean verify
-
-This currently takes about 9 minutes. We don't have a hard limit, but ideally
it should stay within
-30 minutes to 1 hour.
-
-You can skip test categories individually with `-DskipParallelizableITs`,
`-DskipSerialITs` and
-`-DskipIsolatedITs` (`-DskipITs` still works to skip them all at once).
-
-### Configuring MacOS for Simulacron
-
-Simulacron (used in integration tests) relies on loopback aliases to simulate
multiple nodes. On
-Linux or Windows, you shouldn't have anything to do. On MacOS, run this script:
-
-```
-#!/bin/bash
-for sub in {0..4}; do
- echo "Opening for 127.0.$sub"
- for i in {0..255}; do sudo ifconfig lo0 alias 127.0.$sub.$i up; done
-done
-```
-
-Note that this is known to cause temporary increased CPU usage in OS X
initially while mDNSResponder
-acclimates itself to the presence of added IP addresses. This lasts several
minutes. Also, this does
-not survive reboots.
-
-
-## License headers
-
-The build will fail if some license headers are missing. To update all files
from the command line,
-run:
-
-```
-mvn license:format
-```
-
-## Pre-commit hook (highly recommended)
-
-Ensure `pre-commit.sh` is executable, then run:
-
-```
-ln -s ../../pre-commit.sh .git/hooks/pre-commit
-```
-
-This will only allow commits if the tests pass. It is also a good reminder to
keep the test suite
-short.
-
-Note: the tests run on the current state of the working directory. I tried to
add a `git stash` in
-the script to only test what's actually being committed, but I couldn't get it
to run reliably
-(it's still in there but commented). Keep this in mind when you commit, and
don't forget to re-add
-the changes if the first attempt failed and you fixed the tests.
-
-## Speeding up the build for local tests
-
-If you need to install something in your local repository quickly, you can use
the `fast` profile to
-skip all "non-essential" checks (licenses, formatting, tests, etc):
-
-```
-mvn clean install -Pfast
-```
-
-You can speed things up even more by targeting specific modules with the `-pl`
option:
-
-```
-mvn clean install -Pfast -pl
core,query-builder,mapper-runtime,mapper-processor,bom
-```
-
-Please run the normal build at least once before you push your changes.
-
-## Commits
-
-Keep your changes **focused**. Each commit should have a single, clear purpose
expressed in its
-message.
-
-Resist the urge to "fix" cosmetic issues (add/remove blank lines, move
methods, etc.) in existing
-code. This adds cognitive load for reviewers, who have to figure out which
changes are relevant to
-the actual issue. If you see legitimate issues, like typos, address them in a
separate commit (it's
-fine to group multiple typo fixes in a single commit).
-
-Isolate trivial refactorings into separate commits. For example, a method
rename that affects dozens
-of call sites can be reviewed in a few seconds, but if it's part of a larger
diff it gets mixed up
-with more complex changes (that might affect the same lines), and reviewers
have to check every
-line.
-
-Commit message subjects start with a capital letter, use the imperative form
and do **not** end
-with a period:
-
-* correct: "Add test for CQL request handler"
-* incorrect: "~~Added test for CQL request handler~~"
-* incorrect: "~~New test for CQL request handler~~"
-
-Avoid catch-all messages like "Minor cleanup", "Various fixes", etc. They
don't provide any useful
-information to reviewers, and might be a sign that your commit contains
unrelated changes.
-
-We don't enforce a particular subject line length limit, but try to keep it
short.
-
-You can add more details after the subject line, separated by a blank line.
The following pattern
-(inspired by [Netty](http://netty.io/wiki/writing-a-commit-message.html)) is
not mandatory, but
-welcome for complex changes:
-
-```
-One line description of your change
-
-Motivation:
-
-Explain here the context, and why you're making that change.
-What is the problem you're trying to solve.
-
-Modifications:
-
-Describe the modifications you've done.
-
-Result:
-
-After your change, what will change.
Review Comment:
I think this was generally good advice, but not something that has really
been enforced for a while, so +1 to removing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
