[
https://issues.apache.org/jira/browse/CASSANDRA-18665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771583#comment-17771583
]
Josh McKenzie commented on CASSANDRA-18665:
-------------------------------------------
Looks like you get pre-github-PR style JIRA comments from me on this one. :D
- Agree w/Maxim; I think we should drop support for anything not on the
maintained list here: [https://cassandra.apache.org/_/download.html]. There's
a non-trivial burden associated with us carrying these scripts, support, and
artifacts along.
- Consider removing duplication of supported versions between
{{cassandra-artifacts.sh}} and {{{}cassandra-dtest-pytest.sh{}}}; maintenance
error-prone.
- Same for regx_version in {{cassandra-test.sh}} (i.e. having a shared .sh
they all
source w/a function that returns the regx would simplify)
- Consider {{mkdir -p}} instead of {{mkdir}} in execute call in
{{prepare_release.sh}}
to be a bit more fault tolerant. Or nuking and re-creating. /shrug
- Line 288: wildcard {{cp build/cassandra*}} may end up catching things we
don't
want, either now or in the future. Is that the right scope for the glob?
h3. *{{cassandra_job_dsl_seed.groovy}}*
- Is {{dtest-upgrade-upgrade}} a typo on line 74? Only occurrance I could find
in
either this repo or C* proper. Maybe it's supposed to be
{{{}dtest-upgrade-large{}}}?
- Why 600 for the timeout on artifact building? Does that include queue time as
well or just execution? i.e. if the latter... 10 hours is a long time. :)
- In our buildSteps in {{{}matrixPostBuildScript{}}}, it might be nice to get
some kind
of echo of a) how much data we pruned from tmp and /tmp, and b) how much data
we're still using. Something like: \{{find $1 -type f -exec du -ah {} + | sort
-rh | head -n 20}} (or whatever # suits your fancy) has been helpful for some
of my testing to try and find what big consumers are.
- Kind of nitty, but is there a reason we \{{cloneOption { shallow(false) }}}?
Seems we'd save some space by doing shallow of branch only.
- Why are we testing on python3.6? (i.e. we're defaulting to 3.7 in
{{{}docker/run-tests.sh{}}}?)
- Have a diff between {{HEAD}} and {{c2aa282}} camping out around line 823
- Is there any way to get away from the significant redundancy of specifying
the clean commands on each job?
- nit: indentation on Branch Pipelines header comment
h3. *{{.build/docker/ubuntu2004_test.docker}}*
- So the \{1..11}seq for ccm creation - what's the failure rate and reason look
like there? Why 11 attempts?
- If we initialize the ccm repos w/cassandra builds at docker image build time,
we're getting a pretty baked in version of things that needs to be updated
each time we cut a new release right? Why do this at docker image compile
time rather than runtime, and/or just rely on
{{{}cassandra-dtest/upgrade_tests/upgrade_manifes.py{}}}'s list of latest
versions to
correctly pull down and build cassandra instances then?
- Along with that, we pre-cache C* versions on python 3.7 env right? Not on 3.6
or 3.11 which we pull down on the image?
h3. *{{upgrade_base.py}}*
- What's the story with the df and mount debugging on cluster install_dir?
> Update jenkins groovy dsl to use in-tree scripts
> ------------------------------------------------
>
> Key: CASSANDRA-18665
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18665
> Project: Cassandra
> Issue Type: Task
> Components: CI
> Reporter: Michael Semb Wever
> Assignee: Michael Semb Wever
> Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
--
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
