action #55829
closed
defaults section in YAML group settings does not support settings sub-section
Added by asmorodskyi almost 5 years ago.
Updated almost 5 years ago.
Category:
Feature requests
Description
There are a lot of cases when you have some set of test suite settings which applicable for whole job group . so it would be nice if I can write :
defaults:
settings:
VAR1: VAL1
and then all test suites added to this job group will have VAR1
You can currently achieve shared settings via aliasing eg.
- foo: &mysettings
settings:
SPAM: eggs
- foo:
*mysettings
That said, it would make sense to allow settings in defaults and merge them into scenarios the same way it's already allowed for machine and priority vaues.
- Category set to Feature requests
- Target version set to Ready
I agree - it's a natural expectation that this works.
- Status changed from New to In Progress
- Assignee set to livdywan
- Target version changed from Ready to Current Sprint
- Status changed from In Progress to Resolved
it for sure became better , thanks ! but I didn't get why after all settings end up under arch ? and not one level above ?
initially I was thinking about something like :
defaults:
aarch64:
machine: aarch64
priority: 50
settings:
DESKTOP: textmode
EXTRATEST: wicked
KEEP_GRUB_TIMEOUT: '1'
VIDEOMODE: text
WICKED_TCPDUMP: '1'
VIRTIO_CONSOLE_NUM: '2'
x86_64:
machine: 64bit
priority: 50
but I need to duplicate variables under each arch ( I know that I can use variables but it was not the point of this ticket ). I see use case which you was trying to cover with having arch specific variables . But is it possible to have settings in two layers ? with the flow that more specific override more generic
sorry looks like identation not working even under code block , but I hope you get idea ?
Remember to make a space before blocks and lists in markdown ;-)
The default settings map to architectures the same way machine and priority do... so what you're suggesting is inconsistent with how the rest of the definition works, since you place a defaults key in place of an architecture. At least I'd be careful to introduce special-cases like that, if for example using aliases you just need two extra lines to do the same.
What one could do though is define a special key that acts as the default, e.g.:
defaults:
.default: &default
settings:
DESKTOP: textmode
aarch64: *default
Also available in: Atom
PDF