I'll take engagement. Even if it's broadly disagreement. :D (Full disclosure, I have a weak opinion here held weakly): > Wouldn’t we recommend people to use the test images the project CI use? Thus > using in testing the versions we use? I would assume the repeatable CI will > still expect test images the way we have now? Not exactly no. Check out CASSANDRA-18137 <https://issues.apache.org/jira/browse/CASSANDRA-18137>, specifically: > Proposal > • ... > • *CI-agnostic build and test scripts can be run with docker, and without > any CI, on any machine. *
I've been discussing this with mck (and working with him on that patch) and realistically what we have are architectural layers for CI: 1. ant 2. build/test scripts 3. dockerized build/test scripts (using scripts from 2; removes env and setup variability) 4. CI integrations (using 3 or output of 2) 5. CI lifecycle (full stack setup, run, teardown) The debate there would be whether we accept CI results from environments using 2 (build/test scripts), or we require environments to use 3 (docker images so it's all fully uniform). Originally mick and I were leaning towards allowing results from environments using 2 which would then introduce possible drift in OS, JDK, and python env, which is where my questions on this thread came in. Sounds like you were assuming the effort would require 3 Ekaterina? > My concern with this is atrophy; we'll set the version once and when finally > forced to update *In theory* we could pretty easily mitigate this through automation. For instance, having a branch where we run the test suite with no dependencies declared (i.e. run all latest) that we run periodically, and then update the main branch to reflect the last good run from that "always run latest" branch, could give us a blending of both worlds. So technically feasible or not, I think there's a good question that's surfacing here of "what problem would we be trying to solve". I think that pivots on 2 axes: 1. Do we allow folks to certify in a CI environment using build/test scripts but not using specific docker images we provide on the project? 2. How frequently do we see failures in tests (straight failure, flakes, etc) that are due to the versions of dependencies (JDK or python) that we're running the tests with? Regardless of 1, if the answer to 2 is "almost never", then there's likely no bridge to cross here. To your point JD, our pre-reqs for C* installation in our docs explicitly call out "Run Latest JDK", so conforming to that recommendation in our CI environment makes sense to me (see here <https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html#prerequisites>). On Thu, Jun 22, 2023, at 6:47 PM, Jeremy Hanna wrote: > > I like having the latest patch release always brought in for testing and CI > for the JDK versions explicitly supported. So for this release, 11/17. > >> On Jun 22, 2023, at 5:42 PM, Jeremiah Jordan <jeremiah.jor...@gmail.com> >> wrote: >> >> Yes. -1 on forcing the patch release version, and possibly minor version, >> for anything that is not absolutely necessary to do so. Especially for >> things like Java or Python version, I would hope we just install the latest >> Java 8, Java 11, or Java 17 JDK for the platform the image is built from and >> run under them. Otherwise we don’t find out until it’s too late when some >> JDK update breaks things. I know I always tell users to run the latest JDK >> patch release, so we should do the same. >> >> If we want to pin the major version of something, then I have no problem >> there. >> >> -Jeremiah >> >> On Jun 22, 2023 at 5:00:36 PM, Ekaterina Dimitrova <e.dimitr...@gmail.com> >> wrote: >>> Wouldn’t we recommend people to use the test images the project CI use? >>> Thus using in testing the versions we use? I would assume the repeatable CI >>> will still expect test images the way we have now? >>> (I hope I did not misunderstand the question) >>> >>> I also share similar worries with Brandon >>> >>> On Thu, 22 Jun 2023 at 17:48, Brandon Williams <dri...@gmail.com> wrote: >>>> On Thu, Jun 22, 2023 at 4:23 PM Josh McKenzie <jmcken...@apache.org> wrote: >>>> > >>>> > 2. Anyone concerned about us being specific about versions in >>>> > requirements.txt in the dtest repo? >>>> >>>> My concern with this is atrophy; we'll set the version once and when >>>> finally forced to update, find that a lot of other things must also be >>>> updated in order to do so. I think our current approach of only >>>> setting them on things we require at a certain version like thrift has >>>> been successful thus far, and I don't think having different versions >>>> would be very common, but also not really affect repeatability if >>>> encountered. You can see what versions are used from the logs though >>>> and could adjust them to be the same if necessary.
