Discussion: Parameter testDetails:nightlyDefault & weeklyDefault should take precedent over groovy config file

[AdamBrousseau]

What are you trying to do? If we launch a build with a custom list of test buckets, specs that have a hardcoded list in the groovy config file (eg jdk11u_pipeline_config.groovy), ie. ones that are not set as test : 'default', the build ends up testing the hardcoded list rather than the one in the build param. For ex, if we want a build that launches 1 target on all platforms, the specs with the hardcoded lists will launch the entire hardcoded list rather than the single target.

Expected behaviour: Is this expected? Or should the build param trump the file?

Observed behaviour:

Any other comments: Do we adjust the code so the build param takes precedent? If not, is there an alternative solution?

One of our specific examples is specs that run additional targets that most specs don't. We could add another boolean test param into the groovy config file json that would "turn on" those extra targets for those specific specs if the boolean was true. So instead of having the hardcoded list of targets with the addition of sanity.openjdk.xyz we could have something like testEnableXYZ: true. My concern with this approach is we would need another bool for each "feature" we have so it doesn't scale well. The story as is doesn't scale well either and it is a pain to launch a build with 1 target and have a few targets do all testing.

Open to discuss options!

[AdamBrousseau]

cc @llxia