QA » openQA Project

Needs to be discussed with tools team.

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.

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.

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