CASSANALYTICS144: Split testing pipelines out#198
CASSANALYTICS144: Split testing pipelines out#198jmckenzie-dev merged 18 commits intoapache:trunkfrom
Conversation
| # then shard across runners via round-robin on the shuffled order. | ||
| CLASSNAMES=$(find . -name '*Test.java' | cut -c 3- | sed 's@/@.@g' | sed 's/.\{5\}$//' \ | ||
| | python3 -c "import random,sys; lines=sys.stdin.read().splitlines(); random.seed('$GITHUB_SHA'); random.shuffle(lines); print('\n'.join(lines))" \ | ||
| | awk 'NR % 5 == ${{ matrix.job_index }}') |
There was a problem hiding this comment.
[minor] can we have matrix.job_total in-place of hardcoded 5 ?
There was a problem hiding this comment.
Yep - promoted that up.
|
LGTM, can you please share Circle CI pipeline link |
Patch by Josh McKenzie, reviewed by TBD for CASSANALYTICS-144 Breaks out tests to parameterize based on specific cassandra versions. Gradle files will be coupled with CassandraVersion.java but both are commented to indicate their interdependency with one another. Also adds some convenience configurations in intellij config so you can select a specific cassandra version to run tests against at runtime or just choose "test" or "testSequential" to run against all supported major cassandra versions.
MultipleTokens test classes use assumeThat(>= 4.1) in @BeforeAll to skip on Cassandra 4.0. When CI runs these individually via --tests, the skipped @BeforeAll leaves zero discovered tests, causing Gradle to fail with "No tests found." Move failOnNoMatchingTests(false) out of the skipContainerTest guard so it applies unconditionally.
…tBase.java" This reverts commit 8cf8b70.
a3c15e3 to
1f6275a
Compare
|
Here's the circle link from before the above matrix job total promotion: https://app.circleci.com/pipelines/gh/jmckenzie-dev/cassandra-analytics/51/details?job=caad7d43-6be5-43e3-9228-d1691bc2f18a&buildNumber=386&jobType=build&workflowId=9a16c32f-f7eb-4976-97a6-696300e7708f |
|
Here's latest circle pipeline: link |
|
k; CI looks much cleaner than it has been lately. @yifan-c - waiting on you now. |
| INTEGRATION_MAX_PARALLEL_FORKS: 1 | ||
| INTEGRATION_MAX_HEAP_SIZE: "1500M" | ||
| CORE_MAX_PARALLEL_FORKS: 2 | ||
| INTEGRATION_MAX_PARALLEL_FORKS: 2 |
There was a problem hiding this comment.
INTEGRATION_MAX_PARALLEL_FORKS has always been 1. Please revert the change. The in-jvm-dtest cannot run in parallel.
If updating to 2 works, I am good with 2.
There was a problem hiding this comment.
Happy to revert, but also uncertain why the claim they cannot be run in parallel as they're running and passing in both circle and github. There is some flakiness in both env right now but the test failures look to be pre-existing failures or timeouts afaict.
Either way, I'll drop this to 1, bump the heap to 3072 for all integration, and let's see how it runs w/that combo.
There was a problem hiding this comment.
I don't think the original statement is true, we've run integration tests in parallel in the past, not sure if anything changed recently that prevents us from running in parallel
| config: ['s2.13-c5.0.5', 's2.12-c4.1.4', 's2.12-c4.0.17'] | ||
| job_index: [0, 1, 2, 3, 4] | ||
| job_total: [5] | ||
| include: | ||
| - config: 's2.13-c5.0.5' | ||
| scala: '2.13' | ||
| cassandra: '5.0.5' | ||
| - config: 's2.12-c4.1.4' | ||
| scala: '2.12' | ||
| cassandra: '4.1.4' | ||
| - config: 's2.12-c4.0.17' | ||
| scala: '2.12' | ||
| cassandra: '4.0.17' |
There was a problem hiding this comment.
This is the same as the previous matrix with exclusion. Either one is fine.
There was a problem hiding this comment.
I don't understand what you mean here. Are you saying that the previous structure here:
matrix:
scala: [ '2.12', '2.13' ]
cassandra: [ '4.0.17', '4.1.4', '5.0.5' ]
job_index: [ 0, 1, 2, 3, 4 ]
job_total: [ 5 ]
exclude:
- scala: "2.12"
cassandra: "5.0.5"
- scala: "2.12"
cassandra: "4.1.4"
- scala: "2.13"
cassandra: "4.0.17"
before this patch is identical? I agree, but I find the include approach to be easier to reason about than the exclude. i.e. easier to reason about just what we're running directly than to think about the entire spectrum of combinations and carving out parts.
wdyt?
| // - cassandraVersionEnumMap values must match the implemented_versions default | ||
| // - cassandraFullVersionMap values must match the supported_versions default | ||
| ext.cassandraVersionEnumMap = ["4.0": "FOURZERO", "4.1": "FOURONE", "5.0": "FIVEZERO"] | ||
| ext.cassandraFullVersionMap = ["4.0": "4.0.17", "4.1": "4.1.4", "5.0": "5.0.5"] |
There was a problem hiding this comment.
can you add a comment to reference to scripts/build-dtest-jars.sh, the script that builds the cassandra dtest jars?
There was a problem hiding this comment.
Ugh. Added comments in all 3 places (build.gradle, build-dtest-jars.sh, CassandraVersion.java to all reference each other. I'll take a note for a follow up JIRA to have a single source of truth for this that we pull from at build time; this is way too brittle.
|
@yifan-c - Circle CI green, and the failure in github is the reusable cluster problems I'm tackling on CASSANALYTICS-146. maxParallelForks at 1 seems to have gotten in and out in comparable time to 2 in Circle; we can always create a follow up ticket to see if we can push to parallel at 2 w/3G heap each, or even 3.5g each and leave 1G for system. We about ready to merge this one? |
We need to de-parameterize testing, split out to a representative pre-commit smoke test, and ideally randomize our test ordering reproducibly based on the SHA of the commit we're testing. Oh, and probably tune our resource utilization for integration and unit tests.