action #59097
closed
The test result overview page display the test suite name not job template name
Added by Xiaojing_liu over 4 years ago.
Updated over 4 years ago.
Category:
Regressions/Crashes
Description
Example:
The YAML is
defaults:
x86_64:
machine: 64bit
priority: 20
settings:
ISO_MAXSIZE: !!str 4700378000
products:
aaa:
distri: sle
version: 12-SP5
flavor: Server-DVD
scenarios:
x86_64:
aaa:
- create_hdd_textmode_test:
testsuite: create_hdd_textmode
settings:
ISO_MAXSIZE: !!str 47003770
- create_hdd_textmode_test2:
testsuite: create_hdd_textmode
settings:
ISO_MAXSIZE: !!str 470037810
When trigger the test suite using `client isos post TEST=`, the result is
./client isos post --host http://127.0.0.1:9526 DISTRI=sle VERSION=12-SP5 ARCH=x86_64 FLAVOR=Server-DVD BUILD=0287 _GROUP_ID=5 TEST=create_hdd_textmode
{ count => 2, failed => [], ids => [71, 72], scheduled_product_id => 17 }
there are two jobs were triggered. It is expected result.
However, there was only one test result in Test result overview page.
create_hdd_textmode status
Files
- Category set to Feature requests
- Description updated (diff)
- Category changed from Feature requests to Regressions/Crashes
- Target version set to Ready
This is clearly a bug and should be fixed rather soonish if we want to get rid of test suites
Maybe there is a feature request in this ticket. If we write the YAML as the example, and use client isos post TEST=xxx to trigger a job, two jobs are triggered. But if we want to trigger one job with the correct setting, seems like there is no good way to do that. Maybe we could provide a way to trigger job by job_template_name.
- Status changed from New to In Progress
- Assignee set to Xiaojing_liu
- Target version changed from Ready to Current Sprint
@Xiaojing_liu your last update in this ticket was from 19 days ago which is a bit long ago. Would you care to update the ticket with the current status, the problems and the planned next steps?
I tried to fix this ticket in three ways, but they did not work well. the ways were:
- using
settings_hash to get the job_template_name while getting job's information. (when loading all jobs, the performance was very bad.) (the first solution in pr #2468)
- when getting jobs' information, saving all job_template_name as a hash ({job_id => job_template_name, ....}). the performance was very bad if each job has a job_template_name. (the final code in pr #2468)
- when getting a job's information, doing one column search in
job_settings database ($database->search({job_id => xxx, key => 'JOB_TEMPLATE_NAME'})). the performance was bad. (I tested this solution in my local environment using OSD data. Because the performance was bad, I did not commit this code)
So I closed the pull request https://github.com/os-autoinst/openQA/pull/2468.
Try to change the TEST to JOB_TEMPLATE_NAME directly. Commit a new pull request https://github.com/os-autoinst/openQA/pull/2553.
- Status changed from In Progress to Resolved
- Target version changed from Current Sprint to Done
- Status changed from Resolved to In Progress
- Target version changed from Done to Current Sprint
The pr https://github.com/os-autoinst/openQA/pull/2553 has caused a new bug:
- When the parent job is added into YAML with an alias, the
_sort_dep function works wrong.
- when the
START_AFTER_TEST is re-defined in YAML with the parent test's alias, the parent test will not be triggered.
Xiaojing_liu wrote:
The pr https://github.com/os-autoinst/openQA/pull/2553 has caused a new bug:
- When the parent job is added into YAML with an alias, the
_sort_dep function works wrong.
- when the
START_AFTER_TEST is re-defined in YAML with the parent test's alias, the parent test will not be triggered.
Should this be a new ticket? I'm not clear from the last two comments if this ticket is resolved, and/or if there's a new issue here. Could you clarify?
okurz wrote:
We merged this yesterday, it's live on o3. Unless you plan further work yourself we can rebase https://github.com/os-autoinst/openQA/pull/2610 and see what is left to do.
Do you mean we should compare to pr #2610 to see if there is something else we need to do?
Yes. And I suggest to do that by rebasing https://github.com/os-autoinst/openQA/pull/2610 . Anyone can try to do that.
If you do not plan any further steps for this specific ticket yourself I suggest you unassign for the time being. I am also ok if you close the ticket as "Resolved" because the original issue is solved.
okurz wrote:
Yes. And I suggest to do that by rebasing https://github.com/os-autoinst/openQA/pull/2610 . Anyone can try to do that.
If you do not plan any further steps for this specific ticket yourself I suggest you unassign for the time being. I am also ok if you close the ticket as "Resolved" because the original issue is solved.
I prefer to close the ticket as "Resolved". Do I need to add a new ticket for pr #2610?
No, it's ok. Just close this ticket. Eventually I will rebase my PR
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
