[
https://issues.apache.org/jira/browse/CASSANDRA-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790492#comment-17790492
]
Michael Semb Wever commented on CASSANDRA-18731:
------------------------------------------------
bq. Today, our 5.0+ requirements …
Was only a comment to what it today. It can evolve…
bq. Ekaterina Dimitrova made the excellent point that as the JDK authors keep
tightening down what's allowed in terms of unsafe and reflection-based access
If we're confident that CI on the latest JDK is better, sure. But I'm not sold
yet, because there are failures when only coding and testing on highest JDK
beyond the simple compile/classpath type.
bq. 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
Most of the breakages TCM created were because tries and vnodes were not also
run. This is the proof.
We can improve it (more selective to what tests are applicable and to be run
within each variation, etc), but we gotta work with what we know catches
failures today.
bq. Of note - the artifact building bit definitely needs to be resolved;
These all come from in-tree scripts, which must be the shared basis for any CI
system. Moving forward there should not be any excuse that any CI system
doesn't do the artifacts, deb+rpm packaging, and checks.
bq. many of them look to be circle ci env specific and not asf ci
ASF CI was just as _broken_. Including the 5.0 branch from TCM.
bq. 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?
We have a ticket to add it to ASF CI (in-tree scripts), and it was only put on
hold because this ticket was proposing a better approach.
--
We should be using the TCM merge as a valuable use-case to what standard we
need from a CI system.
I am entirely in support of TCM merging when it did – improving every chance of
a release with Accord in it before the Summit is a trade-off in favour of
temporary CI headaches I'll take, and TCM devs have been _very_ quick to
restore CI. Right trade-off, very temporary pain, pragmatic. The very real
(AFAIK) concerns with CI is a) it does deteriorate over time if we're not hyper
vigilant, and b) evaluating CI for patches is very time consuming the more
flakies and failures from elsewhere there are to wade through. It's right that
folk make noise and express their frustration – there is collateral damage.
The biggest priority I see here is that the apple internal ci system is not
using the in-tree scripts. We can live with the ci infra being blackbox (given
what this ticket is otherwise solving), but the scripts need to be transparent
and shared/standard among all CI systems. If we can prioritise evolving the
in-tree scripts that would be appreciated, maybe separating it into a new
ticket (blocking this one). The CI declaration that this ticket brings is the
next priority after that IMO (and requires some broader discussions as we've
both mentioned^^).
> 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
