coordination #93883
closed
[epic] Speedup openQA coverage tests with running minion jobs synchronously using new upstream "perform_jobs_in_foreground" mojo function
Added by okurz over 3 years ago.
Updated over 3 years ago.
Category:
Feature requests
Estimated time:
(Total: 0.00 h)
Description
Motivation¶
With #93086 we found a way to speedup t/10-jobs.t by running minion jobs synchronously from the main process instead of spawning subprocesses and collecting coverage from these because it takes ages. We should apply the same functionality to other test modules, e.g. t/42-df-based-cleanup.t, at best using the new (to come) upstream mojo feature "perform_jobs_in_foreground" and remove workaround for collecting coverage from forked subprocesses. In the end we might want to have only "unit tests" collecting coverage and ensuring complete statement coverage with these while having integration tests simulating more realistic multi-process behaviours.
Acceptance criteria¶
- AC1: All tests have been reviewed to apply the above
- AC2: We are not using the workaround to collect coverage from any subprocesses anywhere by default (could still have a switch which is disabled by default)
Suggestions¶
- Remove t/10-jobs.t from heavy jobs
- We could have an environment variable to switch between "perform_jobs" or "perform_jobs_in_foreground" and combine that with coverage analysis or not
- Remove the workarounds
- Copied from action #93086: unstable test in openQA master t/10-jobs.t exceeding runtime of 280s added
- Subject changed from [epic Speedup openQA coverage tests with running minion jobs synchronously using new upstream "perform_jobs_in_foreground" mojo function to [epic] Speedup openQA coverage tests with running minion jobs synchronously using new upstream "perform_jobs_in_foreground" mojo function
- Status changed from New to Workable
In the weekly estimation meeting we decided that for an epic it's actually "Workable" because we don't need to estimate the epic itself and the next task is simply to refine and create subtasks
- Status changed from Workable to In Progress
- Assignee set to mkittler
All suggestions have been implemented and there's a utility functions making use of "perform_jobs_in_foreground". So several tests have already been changed and resolving the ticket is just a matter of dealing with the remaining ones. I'll check which tests are remaining. If it can be done quickly, I'll change them right away, otherwise I'll create a ticket (and add it as sub task here).
Setting due date based on mean cycle time of SUSE QE Tools
Setting due date based on mean cycle time of SUSE QE Tools
@mkittler what the bot wants to tell you is basically: don't directly "work" on epics :)
- Status changed from In Progress to Feedback
Both PRs merged, what next?
I've been creating sub-tasks for the remaining tests (because changing them maybe takes a little effort).
- Status changed from Feedback to Blocked
- Status changed from Blocked to Resolved
All sub tasks have been resolved so all tests are converted now.
Also available in: Atom
PDF