Project

General

Profile

action #68143

[y] Implement navigation to the schedule from the job

Added by ybonatakis about 1 year ago. Updated about 1 year 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
Difficulty:

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.

History

#1 Updated by riafarov about 1 year 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

#2 Updated by okurz about 1 year ago

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

#3 Updated by riafarov about 1 year ago

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

Needs to be discussed with tools team.

#4 Updated by riafarov about 1 year ago

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

#5 Updated by riafarov about 1 year 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.

#6 Updated by ybonatakis about 1 year ago

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

#7 Updated by ybonatakis about 1 year ago

10024
10027

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.

#8 Updated by ybonatakis about 1 year ago

  • Status changed from In Progress to Feedback

#9 Updated by riafarov about 1 year ago

  • Parent task set to #68525

#10 Updated by riafarov about 1 year 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.

Also available in: Atom PDF