action #68143
closed[y] Implement navigation to the schedule from the job
0%
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
Updated by riafarov over 4 years ago
- Project changed from openSUSE Release Process to openQA Tests (public)
- Due date set to 2020-06-30
- Category set to Infrastructure
- Target version set to future
Updated by okurz over 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
Updated by riafarov over 4 years ago
- Description updated (diff)
- Assignee set to riafarov
- Estimated time set to 13.00 h
Needs to be discussed with tools team.
Updated by riafarov over 4 years ago
- Project changed from openQA Tests (public) to openQA Project (public)
- Category deleted (
Infrastructure)
Updated by riafarov over 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.
Updated by ybonatakis over 4 years ago
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
Updated by ybonatakis over 4 years ago
- File scheduler_link_2020-06-24_07-29.png scheduler_link_2020-06-24_07-29.png added
- File scheduler_2020-06-24_07-28.png scheduler_2020-06-24_07-28.png added
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
And the result is
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.
Updated by ybonatakis over 4 years ago
- Status changed from In Progress to Feedback
Updated by riafarov over 4 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.