Sounds like you were assuming the effort would require 3 Ekaterina? Thank you Josh. Yes, you are totally right. I forgot for a moment that the new scripts are layered. Valid point about 2. Now the question is how fast 2 will be to run it and how many people would actually use it for running full CI.
On Fri, 23 Jun 2023 at 9:37, Josh McKenzie <jmcken...@apache.org> wrote: > 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. > > >
