action #48035
closed
[functional][y] execute SUT setup steps only once per test scenario
Added by okurz about 5 years ago.
Updated about 5 years ago.
Category:
Enhancement to existing tests
Target version:
SUSE QA - Milestone 24
Description
Motivation¶
Whenever we activate terminals we set PS1, ensure proper permissions, disable packagekit, etc. . This is ok when we do it once for the system however in case of xterm we do it every single time we open a new xterm. This wastes quite some time.
E.g. see the minute it took from https://openqa.suse.de/tests/2470038#step/glxgears/3 till https://openqa.suse.de/tests/2470038#step/glxgears/11
We have this issue, as instead of performing these steps in the separate modules, we do it in x11_start_program instead of dedicated module x11_setup.
Other issue that if we execute both x11 tests and console tests, we will run steps multiple times.
Acceptance criteria¶
- Setup steps are executed once in separate test module for x11 tests
Suggestions¶
- We can use the flag to indicate that setup steps were executed
- We still have an issue that we don't share state of the job which has created the job, we might consider getting this feature first
- As this code is used everywhere, we should limit scope of our change, aiming yast2_gui test suite at first place.
- Copied from coordination #47192: [sle][functional][y][epic] some openQA tests in staging take more than 50 minutes added
- Due date set to 2019-03-26
- Copied from deleted (coordination #47192: [sle][functional][y][epic] some openQA tests in staging take more than 50 minutes)
- Blocks coordination #47192: [sle][functional][y][epic] some openQA tests in staging take more than 50 minutes added
- Due date deleted (
2019-03-26)
- Assignee set to okurz
How is that Y? No capacity, neither priority, putting to the product backlog.
- Due date set to 2019-04-09
- Assignee deleted (
okurz)
- Target version changed from Milestone 23 to Milestone 24
riafarov wrote:
How is that Y? No capacity, neither priority, putting to the product backlog.
I put it on the backlog of QSF-y as we talked about it and QSF-y, mainly you, did the last changes in that area regarding "setting serial permissions", stopping getty, etc., especially in the "image generation" context.
"No capacity, neither priority" is something that sounds a bit harsh and also something that the PO should be part of assessing as such, don't you think? So based on the above I hope we have clarified and we can keep it on the backlog of QSF-y as I think you will be way more effective instead of another team that might consequently break e.g. the image creation jobs. I trust you when you mean "not enough capacity in next sprint" however please keep take a bit more shared responsibility as a stand-in for me for all the tickets in the milestone. Removing the due-date means that hopefully the ticket is at least caught in the milestone review which for the next milestone hopefully you would also think about when I will not be there :) How about succeeding sprint in M24?
- Status changed from New to Feedback
- Assignee set to riafarov
- Status changed from Feedback to Workable
- Assignee deleted (
riafarov)
okurz wrote:
@riafarov could you do me the favor and track
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7084
and/or take over? Feel free to close the PR and unassign when you do not want to take the risk of me breaking something ;)
I'll take a look there. But, I'll just put it back to the backlog, especially as it's already scheduled. We will handle this as a team ;). PR looks good, but doesn't appear to be bulletproof, so I won't rush with it.
- Description updated (diff)
- Due date changed from 2019-04-09 to 2019-04-23
riafarov will refine it better
- Subject changed from [functional][y] improve runtime of terminal enablements, especially xterm to [functional][y] execute SUT setup steps only once per test scenario
- Description updated (diff)
We need to check with @riafarov about where exactly those steps are set, team is not clear about where to find the info.
- Status changed from Workable to Rejected
- Assignee set to riafarov
It's actually is solved already. I remembered myself putting code in x11_start_program to play it safe. In the mentioned examples, there is nothing triggered when xterm is started.
PR solves something else, which is more about minor optimizations. So I reject the ticket, PR is still useful and helpful, so let's review and merge it but as something not related to this particular task.
Also available in: Atom
PDF