action #55829

defaults section in YAML group settings does not support settings sub-section

Added by asmorodskyi 8 months ago. Updated 7 months ago.

Status:ResolvedStart date:22/08/2019
Priority:NormalDue date:
Assignee:cdywan% Done:


Category:Feature requests
Target version:Current Sprint


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 :


and then all test suites added to this job group will have VAR1


#1 Updated by cdywan 8 months ago

You can currently achieve shared settings via aliasing eg.

- foo: &mysettings
      SPAM: eggs
- foo: 

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.

#2 Updated by coolo 7 months ago

  • Category set to Feature requests
  • Target version set to Ready

I agree - it's a natural expectation that this works.

#3 Updated by cdywan 7 months ago

  • Status changed from New to In Progress
  • Assignee set to cdywan
  • Target version changed from Ready to Current Sprint

#4 Updated by cdywan 7 months ago

  • Status changed from In Progress to Resolved

#5 Updated by asmorodskyi 7 months ago

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 :

    machine: aarch64
    priority: 50
    DESKTOP: textmode
    EXTRATEST: wicked
    VIDEOMODE: text
    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

#6 Updated by asmorodskyi 7 months ago

sorry looks like identation not working even under code block , but I hope you get idea ?

#7 Updated by cdywan 7 months ago

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.

#8 Updated by okurz 7 months ago

What one could do though is define a special key that acts as the default, e.g.:

  .default: &default
      DESKTOP: textmode

  aarch64: *default

Also available in: Atom PDF