[y] Implement navigation to the schedule from the job
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.
#5 Updated by riafarov over 1 year ago
- Status changed from New to Workable
- Assignee deleted (
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.
#7 Updated by ybonatakis over 1 year 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
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:firstname.lastname@example.org). 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_SCHEDULEemail@example.com. The routing in this example will match the
schedule/ and will store
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_path be the remain of the variable path.
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.