QA (public) » openQA Project (public)

related: https://progress.opensuse.org/issues/14964

I would recommend to add some basic tests to this route - as it's so seldomly used we discover regressions only late otherwise

PR for tests: https://github.com/os-autoinst/openQA/pull/1327

Apparently https://github.com/os-autoinst/openQA/pull/1318 broke something.

observation¶

Trying to add zdup_13.2_cryptlvm@uefi in Jobs for openSUSE Leap 42.3 in opensuse-42.3-DVD on https://openqa.opensuse.org/admin/job_templates/28 fails with "wrong parameter: machine_id". Checking the POST request I can see that the parameter is not set at all. It looks like this is caused by "filterTestSelection" within job_templates.js being called on the current index but the problem could so far be reproduced only for this specific value. I could reproduce the problem also based on the database dump from 2017-05-28 on my machine

steps to reproduce¶

• go to https://openqa.opensuse.org/admin/job_templates/28
• try to add "uefi" to zdup_13.2_cryptlvm on the DVD group
• observe the error

To reproduce locally use database dump from o3.

It seems the PR adding tests https://github.com/os-autoinst/openQA/pull/1327 is not testing the part about trying to define an actual scenario on the second test selection. It only looks for test suites selections and also this part might miss the fact that actually the same test suite can be added twice - which it probably shouldn't.

https://github.com/os-autoinst/openQA/pull/1349 created to temporarily revert.

I created another PR which fixes the issue mentioned in the previous comment by @okurz. It simply occurred because uefi is in both columns (Tests and x86_64).

But as discussed with @okurz the issue isn't solved yet because the current approach doesn't handle the case where product_id machine_id and test_suite_id are identical but the job group differs. I suppose in this case it is not a good idea to just remove the conflicting entries from the selection. Otherwise the user would wonder why entries are missing. It is not obvious why the entries are missing because the conflicting templates are on a different job template page in this case. Instead the error message should tell the user on which job template page the conflicting template is. By the way, does it even make sense that group_id is not part of the unique constraint?

In order to distinguish the unique constraint error from other database errors the error handling in line https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI/Controller/API/V1/JobTemplate.pm#L111 must be improved. However, I'm currently unable to do it. I discovered the following options, but I'm not sure how to continue:

• In other places we're using try-catch via Try::Tiny but it only provides an error string, too. The fact that the error string is even localized does not make parsing easier.
• There is DBIx::Error but it is not packaged yet. It also seems a bit unreasonable to add an extra dependency for this.
• It seems to be possible to register a custom error handler, but that's connection-wide and hence not convenient to use and might break other places.
• As a workaround just check the constraint violation manually.

Note that in my previous comment I confused this with the exception you still get when adding a new test suite with a name which already exists. But according to the screenshot this is actually about job templates and yes - I fixed it a while ago.