> 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 the patching logic… I > had another JIRA to have a python script rewrite the YAML, but this method > may solve in a cleaner way.
Almost any part of a CircleCI definition can be replaced with a parameter, so basically we want config-2_1.yml to be a template, and we plug different values in as desired. Would you mind sending a link to that JIRA so I can understand that use case? > About matrix jobs; I don’t know them in circle but have used in other places, > this sounds good to me. I would also enhance to argue that JVM is just 1 > config and we sadly have many more: > > JVM: [8, 11, 17] > VNODE: [true, false] > CDC: [true, false] > COMPRESSION: [true, false] > MEMTABLE: [skiplist, shardedskiplist, trie] My understanding is that we could parameterize all of these such that we could use a matrix as long as all combinations are valid. Let me get parameterization of basic configuration reviewed first, and then we can take a look at how to matricize things. Cheers, Derek -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+
