action #56279: "Preview changes" after Job Group YAML edit should allow to see changes in "resulting YAML" - openQA Project (public) - openSUSE Project Management Tool

Actions

Copy link

action #56279

closed

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

Added by asmorodskyi over 5 years ago. Updated almost 5 years ago.

Status:

Resolved

Priority:

Low

Assignee:

livdywan

Category:

Feature requests

Target version:

Current Sprint

Start date:

2019-09-02

Due date:

% Done:

Estimated time:

Description

current behavior:

after edit of current Job Group you may push "Preview Changes"
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"

Actions

Copy link

Updated by coolo over 5 years ago

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

Actions

Copy link

Updated by asmorodskyi over 5 years 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

Actions

Copy link

Updated by livdywan over 5 years ago

Description updated (diff)

Actions

Copy link

Updated by livdywan over 5 years 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.

Actions

Copy link

Updated by okurz over 5 years 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

Actions

Copy link

Updated by coolo over 5 years ago

Priority changed from Normal to Low
Target version set to Ready

We will get to it eventually

Actions

Copy link

Updated by livdywan about 5 years 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

Actions

Copy link