Project

General

Profile

Actions

action #68143

closed

[y] Implement navigation to the schedule from the job

Added by ybonatakis almost 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
2020-06-16
Due date:
2020-06-30
% Done:

0%

Estimated time:
13.00 h

Description

As tester
I want to be able to navigate easily to the schedule file of the test

we can implement same handling as we have for test modules code.

We can have it handled in similar way as test module code or at least have some improved usability using.


Files

Actions #1

Updated by riafarov almost 4 years ago

  • Project changed from openSUSE Release Process to openQA Tests
  • Due date set to 2020-06-30
  • Category set to Infrastructure
  • Target version set to future
Actions #2

Updated by okurz almost 4 years ago

Is this referring to the logs provided by openQA? Then I suggest to move this to https://progress.opensuse.org/projects/openqav3

Actions #3

Updated by riafarov almost 4 years ago

  • Description updated (diff)
  • Assignee set to riafarov
  • Estimated time set to 13.00 h

Needs to be discussed with tools team.

Actions #4

Updated by riafarov almost 4 years ago

  • Project changed from openQA Tests to openQA Project
  • Category deleted (Infrastructure)
Actions #5

Updated by riafarov almost 4 years ago

  • Status changed from New to Workable
  • Assignee deleted (riafarov)

So after discussion with Oliver, we should try to make that feature usable not only for os-autoinst-distri-opensuse. As we have mentioned while refining, we have other variables like AUTOYAST, which could benefit from it, so users can navigate to the source of the file from the job directly.

Actions #6

Updated by ybonatakis almost 4 years ago

  • Status changed from Workable to In Progress
  • Assignee set to ybonatakis

Updated by ybonatakis over 3 years ago

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

The draft shows a possible implementation. the settings shows the yaml scheduler as a link. The link points to the path of the file (for example http://127.0.0.1:8881/tests/15/schedule/yast/ext4/ext4@yast.yaml). The endpoint calls the controller and reads the file and displays it as it happens with the src of the modules.

to do so we create the endpoint which will host the yaml output. for the scheduler is /schedule/*scheduler_path. We set YAML_SCHEDULE=schedule/yast/ext4/ext4@yast.yaml. The routing in this example will match the schedule/ and will store yast/ext4/ext4@yast.yaml in scheduler_path. This can be generalized and match whatever we like, instead of schedule. i didnt try but i believe that using get(/:test_file/*test_file_path => [test_file => ['schedule', 'autoyast']]) will create a placeholder for either in :test_file with *test_file_path be the remain of the variable path.

The settings.html.ep is the template that is render when we visits the settings tab e.g http://127.0.0.1:8881/tests/15/#settings. The template is coded to present links only for http(s) prefixes. As a regex is easy to just add the prefixes that we want to include. This would be the minimal effort to achieve linking on the settings. otherwise the Mojo::Template can run code to handle this, if we want. For instance, a more 'sophisticated' idea, could read the variables from vars.json and create a link to repo that contains the yaml file.

When the link is clicked will call the associated method in the controller which reads the file and renders the templates with its context.

The settings will appear as is shown in this screenshoot
#settings

And the result is
/tests/15/schedule/yast/ext4/ext4@yast.yaml

The link above doesnt provide complete code.

UPDATE: The user sees the version of the file which is present in the web UI's checkout of the test distribution. That's not necassarily the same version used to run the test.

Actions #8

Updated by ybonatakis over 3 years ago

  • Status changed from In Progress to Feedback
Actions #9

Updated by riafarov over 3 years ago

  • Parent task set to #68525
Actions #10

Updated by riafarov over 3 years ago

  • Status changed from Feedback to Resolved

Good job here. As per our discussion, please create follow-up ticket to complete implementation and add it to the next sprint.

Actions

Also available in: Atom PDF