[
https://issues.apache.org/jira/browse/CASSANDRA-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790270#comment-17790270
]
Josh McKenzie commented on CASSANDRA-18731:
-------------------------------------------
{quote}Today, our 5.0+ requirements to the CI pre-commit pipeline are...
{quote}
I think we should revisit this on the dev ML; I don't fully agree w/what you've
outlined above and this is something we should discuss as a project community,
not mandate on a comment in a JIRA.
[~e.dimitrova] made the excellent point that as the JDK authors keep tightening
down what's allowed in terms of unsafe and reflection-based access, we're more
likely to see failures on the highest supported JDK version rather than the
lowest for example, meaning the python dtest suites and jvm-dtest-upgrade
should likely be calibrated to "highest supported and down", vs. "lowest
supported and up".
Further, I don't agree with (and we've discussed) the need to run test-cdc (or
it existing at all vs. it just being enabled for all tests), the compression,
oa, or trie suites as pre-commit smoke suites, etc. I have a strong belief that
we should expect very infrequent test failures on non-default configurations
vs. the base; that functionality is supposed to be API compatible and if it
works on one configuration, it works on all. While there will no doubt be
flakes, the amount of compute required to run all those pre-commit as a smoke
suite effectively removes the "smoke" aspect of it and just makes pre-commit a
vast majority of the cost of a full run.
Same for testing everything in no-vnode and vnode combination; that's so
terribly wasteful that I just can't agree with doing that for everything
pre-commit (in any env, circle, new, or ASF-CI). I would very much prefer we
take the approach you enumerated on the dev ML:
{quote}Can we get these tests temporarily annotated as skipped while all the
subtickets to 19055 are being worked on ?
{quote}
We have the current example of the TCM merge on CASSANDRA-19055 to immediately
inspect as to whether this approach is sufficient or not. With an _incredibly
large_ patch in the form of TCM (88k+ LoC, 900+ files touched), we have less
than a .002% test failure injection rate using the above restricted smoke
heuristic, and many of them look to be circle ci env specific and not asf ci.
(Of note - the artifact building bit definitely needs to be resolved; we should
consider extending an "artifact build only" target on ASF CI people can
parameterize with feature branches to make sure they haven't broken the various
builds?)
And for repeated runs, we discussed the fact that not having support for
repeated runs in ASF CI meant we also didn't want to put down a hard blocker on
requiring those runs on other pre-commit environments. Has your position
changed on that? Regardless, that's just a question of prioritization; it's
relatively trivial to finish up support for that if we deem it an immediate
priority.
> Add declarative root CI structure
> ---------------------------------
>
> Key: CASSANDRA-18731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18731
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
> Reporter: Josh McKenzie
> Assignee: Josh McKenzie
> Priority: Normal
> Fix For: 5.x
>
>
> Currently we have a somewhat declarative structure in .circleci, however
> there's still quite a bit that's baked in (resource limitations, parallelism,
> which suites qualify for which pipelines (pre-commit vs. post-commit vs.
> ???), etc). Further, while CASSANDRA-18133 brings the build scripts in-tree,
> all these parameters (pipelines, env vars, job definitions, resource
> constraints) are all still scattered throughout the shell scripts and/or
> reliant on the {{JenkinsFile}} to determine what suites comprise what
> pipelines.
> This ticket aims to decouple the definition of pipelines and jobs for CI from
> the implementations themselves. The goal here is to define, establish, and
> test both the base config and some helper methods to provide _other_
> configurations (circle, ASF CI, etc) the tools they need to programmatically
> inherit base CI config from a purely declarative structure.
> Follow-up tickets will involve rewriting the in-tree build scripts and
> JenkinsFile generation to rely on this structure, as well as integrating the
> config parsing unit tests into our CI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
