action #56279

"Preview changes" after Job Group YAML edit should allow to see changes in "resulting YAML"

Added by asmorodskyi 6 months ago. Updated about 1 month ago.

Status:ResolvedStart date:02/09/2019
Priority:LowDue date:
Assignee:cdywan% Done:

0%

Category:Feature requests
Target version:Current Sprint
Difficulty:
Duration:

Description

current behavior:

  1. after edit of current Job Group you may push "Preview Changes"
  2. depending on what exactly you did during edit phase you will see
    1. "No changes was made!" message informing you that you actually haven't done anything
    2. list of errors in case you modify YAML not corretly
    3. diff between what was before in YAML which you edit and what you about to save

Suggestion : in case of 2.3 need to add ability to preview "resulting YAML"

Note 1: "resulting YAML" is just random term which I use to identify YAML which was displayed in some previous stages of Job Group YAML editor development process when after pressing on "Preview Changes" was displayed YAML which appears after processing all variables to real value . So one can also call it "raw YAML". Correct term need to be defined for this view

Note 2: ability to preview "resulting YAML" should be provided by adding additional control which allowing to switch content of memo control which currently displaying diff of changes in "current YAML"

History

#1 Updated by coolo 6 months ago

What resulting Yaml? I don't get it. You edit yaml and that's saved as edited

#2 Updated by asmorodskyi 6 months ago

coolo wrote:

What resulting Yaml? I don't get it. You edit yaml and that's saved as edited

I am speaking about what we had before https://github.com/os-autoinst/openQA/pull/2252 . When you press "Preview Changes" button those day you will see your "current YAML" but rendered . Meaning that for example all blocks like this:

scenarios:
  aarch64:
    sle-12-SP5-Server-DVD-aarch64:
    - wicked_basic_sut: &general_settings
        settings:
          DESKTOP: textmode
          EXTRATEST: wicked
          KEEP_GRUB_TIMEOUT: '1'
          VIDEOMODE: text
          WICKED_TCPDUMP: '1'
    - wicked_advanced_ref: 
        *general_settings

will be replaced with something like this:

scenarios:
  aarch64:
    sle-12-SP5-Server-DVD-aarch64: 
    - wicked_basic_sut: 
        settings:
          DESKTOP: textmode
          EXTRATEST: wicked
          KEEP_GRUB_TIMEOUT: '1'
          VIDEOMODE: text
          WICKED_TCPDUMP: '1'
    - wicked_advanced_ref: 
        settings:
          DESKTOP: textmode
          EXTRATEST: wicked
          KEEP_GRUB_TIMEOUT: '1'
          VIDEOMODE: text
          WICKED_TCPDUMP: '1'

Not that I want to revert that patch but I want to extend it . Because there are scenarios when such kinda information also brings value

#3 Updated by cdywan 6 months ago

  • Description updated (diff)

#4 Updated by cdywan 6 months ago

Thanks for providing the example! Please note the spacing around code blocks, otherwise they're just displayed as regular text. I fixed the markup to make it work.

coolo wrote:

What resulting Yaml? I don't get it. You edit yaml and that's saved as edited

Anton is referring to the "expanded" YAML you get where references or defaults are merged from the user's perspective. In technical terms this is the YAML that's generated based on the definitions in the database, which is also used for groups that haven't been migrated yet.

I think it's a great suggestion. My slight concern here is ease of use of the UX. In the given example it's probably obvious what you're looking at. In some cases it would just look like a rearrangement.

We should probably also consider #55454 here, which will add another dimension to the result ie. more settings will be effectively used in the scenario that weren't specified in the YAML.

#5 Updated by okurz 6 months ago

  • Subject changed from "Preview changes" after Job Group YAML edit should aloow to see changes in "resulting YAML" to "Preview changes" after Job Group YAML edit should allow to see changes in "resulting YAML"
  • Category set to Feature requests

#6 Updated by coolo 6 months ago

  • Priority changed from Normal to Low
  • Target version set to Ready

We will get to it eventually

#7 Updated by cdywan 4 months ago

I realized after the recent code refactorings we could regenerate a result preview without even touching the database, so I went ahead and made a branch.

Are we okay with rendering the result via the Preview feature, and reporting the diff while Save'ing? I went for the least intrusive approach. Otherwise we'll need to agree on a more complex design here.

https://github.com/os-autoinst/openQA/pull/2399

#8 Updated by okurz 4 months ago

sounds good to me. Take the ticket :)

#9 Updated by cdywan 4 months ago

  • Status changed from New to In Progress
  • Assignee set to cdywan

#10 Updated by cdywan 4 months ago

  • Target version changed from Ready to Current Sprint

#11 Updated by cdywan 3 months ago

  • Status changed from In Progress to Feedback

#12 Updated by cdywan about 1 month ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF