michaelsembwever commented on code in PR #1378:
URL:
https://github.com/apache/cassandra-spark-connector/pull/1378#discussion_r2059549026
##########
.github/workflows/main.yml:
##########
@@ -16,15 +14,13 @@ jobs:
fail-fast: false
matrix:
scala: [2.12.19, 2.13.13]
- db-version: [3.11.17, 4.0.12, 4.1.4, 5.0-beta1, dse-6.8.44]
+ db-version: [3.11.19, 4.0.17, 4.1.8, 5.0.4, dse-6.8.44]
steps:
- uses: actions/checkout@v4
- - name: ccm pip installation
- uses: BSFishy/pip-action@v1
- with:
- packages:
git+https://github.com/riptano/ccm.git@d74db63d75112908a77b6c80757df9343fdc3338
+ - name: Install ccm via pip
+ run: pip install git+https://github.com/apache/cassandra-ccm.git@trunk
Review Comment:
Ideally it would be best to test against both the last stable version of CCM
as well as its trunk. But there are no versions of CCM (currently), and the QA
stability benefit of `cassandra-test` over `trunk` is little.
Failures would be a CCM breakage, to be caught early and reported back to
CCM.
A separate reason/question between the `cassandra-test` vs `trunk` choice is
atomicity of the ccm used within each CI run. The main benefit I've seen of
using the `cassandra-test` tag is to ensure it's only changed in between CI
runs, so we don't get mixed results. (We don't expect ccm devs to be holding
back commits to trunk and being conscious of what CI is doing, but they need to
be when re-tagging `cassandra-test`.) While I doubt anyone will be checking
GHA runs from this repo before re-tagging `cassandra-test`, it might still have
some benefit 🤷
what's the verdict ?
--
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]
