Re: A proposal for refactoring the CircleCI config

It seemed like a lot of other changes were happening around the CircleCI config, so I was holding off on the parameterization. I would be happy to work with Claude for the changes if that’s already in progress, though. Cheers, Derek From: "Claude Warren, Jr via dev" Reply-To: "dev@cassandra.a

Re: A proposal for refactoring the CircleCI config

I have been working on https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-18012 which modifies the generate.sh script for the circleci configurations. Perhaps all of this should be rolled into one change? On Fri, Nov 11, 2022 at 3:47 AM Ekaterina Dimitrova wrote: > Hey Derek, > T

Re: A proposal for refactoring the CircleCI config

Hey Derek, Thanks for looking into this. As we spoke in Slack, probably an easy way to show people how things will look like is to have a prototype with some minimal config. Could be even not Cassandra one but something that will show how things will look like and improve the current model. Thanks,

Re: A proposal for refactoring the CircleCI config

Here is the ticket I was talking about https://issues.apache.org/jira/browse/CASSANDRA-17600 > On Nov 2, 2022, at 1:29 PM, Derek Chen-Becker wrote: > >> For the parallel param logic, sounds fine to me. Not sure if this would >> also wo

Re: A proposal for refactoring the CircleCI config

> For the parallel param logic, sounds fine to me. Not sure if this would also > work for resource_type, but I still argue that xlarge isn’t needed in 90% of > the cases its used… so fixing this may be better than param there…. So yes, I > would be cool with this change if it basically removes

Re: A proposal for refactoring the CircleCI config

Thanks for starting this thread! If I am reading correctly, there are 2 main improvements proposed: move parallel value to a param and have our “patches” update those and not the jobs themselves, look into / use matrix to define the set of jobs we need… For the parallel param logic, sounds fine