QA » openQA Project

I suppose adding the parameter table involves the following steps:

1. Create the tables TestParameter and TestParameterSettings similar to the existing tables TestSuites and TestSuiteSettings. I'd say the parameters should also have the description field like the test suites have.
2. Extend the JobTemplates table to store optionally a test_parameter_id which is a foreign key to the table TestParameter created in 1.
3. Extend the YAML import/export to support the column added in 2. Also extend the example shown in the UI accordingly.
4. 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.
5. 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.
6. 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 TEST setting 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.
7. Add support for the new table in dump templates and load templates scripts.

@coolo Does this make sense for you?

@cdywan I could start with 1. and 2. and you could continue with 3. while I'll continue with 4. I would wait for feedback from @coolo before starting.

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.

So this does not add "another dimension" after all. It just extends an existing dimension with parameters. That means we could actually make this accessible in the current job template editor as well by inserting another column next to the priority.

PR for dump_templates/load_templates support: https://github.com/os-autoinst/openQA/pull/2074

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

To avoid unintended overwriting of each other's changes, I suggest to put a revision (or timestamp) next to the yaml to be checked if it stayed the same between load and save.