[
https://issues.apache.org/jira/browse/CASSANALYTICS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANALYTICS-144:
----------------------------------------
Description:
In CASSANALYTICS-122, we made changes to circleci config to prevent some error
100's that showed up after CASSANALYTICS-60. It looks like test
parameterization plus bridge plus some changes to heap pressure may have tipped
us over an edge we were teetering on for awhile.
We need to hard constrain things in base build.gradle files to no daemon, max
workers 1, and heap max 2048 for test instances instead of having a circleci
specific band-aid. Kind of a "global temporary band-aid" of sorts. The goal is
to get things correct at the root so we can then start to relax constraints to
speed them up with some more intentionality around how we constrain execution
environments.
Ideally we also need to specify and document the intended CI execution
environment constraints in terms of CPU and memory so we know what our
requirements are to stay within.
Edit 4/9: Going to just repurpose this one to break up our CI pipelines to
pre/post CL 5.0 format / pipeline them by CL format so we can work past this
major regression.
was:
In CASSANALYTICS-122, we made changes to circleci config to prevent some error
100's that showed up after CASSANALYTICS-60. It looks like test
parameterization plus bridge plus some changes to heap pressure may have tipped
us over an edge we were teetering on for awhile.
We need to hard constrain things in base build.gradle files to no daemon, max
workers 1, and heap max 2048 for test instances instead of having a circleci
specific band-aid. Kind of a "global temporary band-aid" of sorts. The goal is
to get things correct at the root so we can then start to relax constraints to
speed them up with some more intentionality around how we constrain execution
environments.
Ideally we also need to specify and document the intended CI execution
environment constraints in terms of CPU and memory so we know what our
requirements are to stay within.
> Revert parameterized testing to stabilize CI resource usage
> -----------------------------------------------------------
>
> Key: CASSANALYTICS-144
> URL: https://issues.apache.org/jira/browse/CASSANALYTICS-144
> Project: Apache Cassandra Analytics
> Issue Type: Task
> Reporter: Josh McKenzie
> Assignee: Josh McKenzie
> Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANALYTICS-122, we made changes to circleci config to prevent some
> error 100's that showed up after CASSANALYTICS-60. It looks like test
> parameterization plus bridge plus some changes to heap pressure may have
> tipped us over an edge we were teetering on for awhile.
> We need to hard constrain things in base build.gradle files to no daemon, max
> workers 1, and heap max 2048 for test instances instead of having a circleci
> specific band-aid. Kind of a "global temporary band-aid" of sorts. The goal
> is to get things correct at the root so we can then start to relax
> constraints to speed them up with some more intentionality around how we
> constrain execution environments.
> Ideally we also need to specify and document the intended CI execution
> environment constraints in terms of CPU and memory so we know what our
> requirements are to stay within.
> Edit 4/9: Going to just repurpose this one to break up our CI pipelines to
> pre/post CL 5.0 format / pipeline them by CL format so we can work past this
> major regression.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
