- Add parameter table and its relationship with job_templates table.
- Extend format defined in https://progress.opensuse.org/issues/46667 to support parameter table.
- Add some kind of UI to support that feature (minimum would be a text area with the YAML representation).
#1 Updated by mkittler over 2 years ago
I suppose adding the parameter table involves the following steps:
- Create the tables
TestParameterSettingssimilar to the existing tables
TestSuiteSettings. I'd say the parameters should also have the description field like the test suites have.
- Extend the
JobTemplatestable to store optionally a
test_parameter_idwhich is a foreign key to the table
TestParametercreated in 1.
- Extend the YAML import/export to support the column added in 2. Also extend the example shown in the UI accordingly.
- Create a new "admin table page" in the web UI to allow editing tables created in 1. similar to the existing page for editing test suites. This should be easily done without duplicating much code because existing admin tables also share common code already.
- Make the algorithm for scheduling products use of the parameters. I assume it should do what it already does so far and if a job template has parameters it simply adds those settings, too.
- The test suite descriptions we have so far are shown as 'scenario description' in the test result pages in in the test overview pages. For this, the
TESTsetting of the job simply has to match the test suite name. It might be good if parameter descriptions would be shown in a similar way. However, I'm not sure how the mapping should be done.
- Add support for the new table in dump templates and load templates scripts.
coolo Does this make sense for you?
#2 Updated by coolo over 2 years ago
Sorry for the delay, but this is the wrong direction (so thanks for waiting :)
The parameters shouldn't be top level admin entries, but belong to the scheduled entry in the job group. If the job group is done, the parameter is gone as well. I.e. the we schedule TEST install_desktop+test_application in a job group.
And you once schedule it with DESKTOP=kde,APPLICATION=firefox and once with DESKTOP=gnome,APPLICATION=evince (the example is of course completely nonsense, but I hope it explains my point).
As such the parameters are purely edited within yaml of the job group.
#8 Updated by cdywan over 2 years ago
The next steps as of today's weekly meeting:
- Save the YAML in the database
- Disable legacy UI once YAML is present for a template
- There is no support for parameters w/o YAML
- Lock API calls that affect a YAMLized template
- No git backend for now
- Remove the preview, validation is mandatory when saving
- Post an announcement to the mailing list
#11 Updated by mkittler over 2 years ago
- Status changed from In Progress to Blocked
- Assignee changed from cdywan to mkittler
@cdwywan In addition to your list there are also the following TODOs: https://github.com/os-autoinst/openQA/pull/2074#issuecomment-496431091 (point "There is no support for parameters w/o YAML" is covered by both lists)
Note that the TODOs I commented on the PR are actually the ones this issue is about. The points mentioned by cdywan are different tasks and some of them block this issue.
#12 Updated by cdywan over 2 years ago
- Status changed from Blocked to In Progress
- Assignee changed from mkittler to cdywan
One additional point as per today's meeting:
- Remove the name from the YAML ie. lose the group name
We don't want to support editing the name or creating new groups right now, or any other settings.