Cassandra offerings are very outdated

[alexflav23]

Hi guys,

Travis is starting to get very seriously out of date with Cassandra features, it's becoming difficult to use, especially since sudo is not possible on container infrastructure and therefore I don't think users can manually install this. In the pre-container days the manual setup wouldn't have been a problem, but there should be an option to have a bunch of Cassandra variants pre-installed.

Considerations

You have several possible issues to address here, namely if people want to test with DSE or for instance something like Datomic, there is a known Cassandra version limit supported. The longest term

Suggested fix

A variation of the services: - cassandra initialisation bit already supported by Travis would be best suited if it accounted for the Cassandra version, and that kind of syntax was previously suggested. E.g, having the ability to call:

services:
  - cassandra32

This can get problematic in the sense that all the default directories would likely also need post-fixing for the sake of completeness, but assuming no one wants to use more than one Cassandra version for the same build, you could probably skip this step completely. It would look like this:

- /var/lib/cassandra$version
- /var/log/cassandra$version

As the author of the Scala driver for Cassandra, I really wouldn't mind the ability to test several major Cassandra versions per build, using env.matrix, however this is currently impossible, and this certainly goes beyond the current problem.

Which version to install

The newest available version is already 3.7. The changelog is here, but given the release 2.0.9 you are currently using dates back to June 30th, 2014, using Travis with Cassandra based applications is becoming very very problematic.

I'm sure many others can be counted here, we are now in a place where we are forced to consider other build tools because a dependency bump takes 2 years, all our internal apps have increasingly more test level workaround the Travis Pro version of C*. There are major CQL changes that we cannot work around, and the list of features in our applications which remain un-tested because tests are disabled at build time is an amount of technical debt we cannot ignore.

We have taken the alternative approach of using our own phantom-sbt plugin which captures a very small subsegment of Cassandra users, namely those who have SBT based projects. This allows spawning an embedded in memory instance for tests to run against, but other users who do not share this setup cannot benefit from the approach.

Are there any plans to address this?

Regards.

[meatballhat]

One possible solution would be to handle such things at travis-build time, perhaps with the use of https://github.com/pcmanus/ccm. This is how the gocql project does it, fwiw:

Installing ccm: https://github.com/gocql/gocql/blob/b2caded3d0f457e42515c06d4092c02055cebaa0/.travis.yml#L33-L35
Using ccm: https://github.com/gocql/gocql/blob/b2caded3d0f457e42515c06d4092c02055cebaa0/integration.sh

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues