Project

General

Profile

Actions

action #157342

closed

coordination #154768: [saga][epic][ux] State-of-art user experience for openQA

coordination #157345: [epic] Improved test reviewer user experience

Partial product re-scheduling scheduled whole build

Added by pcervinka 8 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2024-03-15
Due date:
% Done:

0%

Estimated time:

Description

We have development group for 15-SP6 Online x86_64 architecture https://openqa.suse.de/group_overview/507.
There was missing HDD_1 and job failed https://openqa.suse.de/tests/13783898/modules/boot_to_desktop/steps/4.
We fixed the configuration and we clicked on Parial product re-scheduling:

It should re-schedule partially, at least this is our understanding of help description.

Unfortunately, it rescheduled whole x86_64 medium for 15-SP6 Online.

It is either bug in the re-scheduling code or help description is wrong. User has expectation (based on help) that re-schedules only his job and its children or that job group.
Could you please investigate it ?


Files


Related issues 1 (0 open1 closed)

Related to openQA Project - action #138593: Restart of scheduled products is prone to retriggers by humans size:SResolvedmkittler2023-10-26

Actions
Actions #1

Updated by okurz 8 months ago

  • Project changed from openQA Tests to openQA Project
  • Category changed from Bugs in existing tests to Feature requests
  • Target version set to Tools - Next
Actions #2

Updated by acervesato 8 months ago

In my opinion, it makes sense to threat it as a bug, considering how clear it is the help documentation on that specific feature. It's kinda awkward that by scheduling a single job we affect a chain as a whole and other people work as well.

Actions #3

Updated by okurz 8 months ago

  • Related to action #138593: Restart of scheduled products is prone to retriggers by humans size:S added
Actions #4

Updated by okurz 8 months ago

  • Parent task set to #157345
Actions #5

Updated by mkittler 6 months ago

Without knowing the dependency tree of the specific job it would involve a lot of guesswork to work on this.

Note that the partial re-triggering feature was designed to decide what re-schedule based on job dependencies (as I suppose this was the initial requirement for the feature). So it is expected that it doesn't stop at job group boundaries if the dependency tree contains jobs across different job groups.

Actions #6

Updated by okurz 5 months ago

  • Target version changed from Tools - Next to Ready
Actions #7

Updated by okurz 5 months ago

  • Target version changed from Ready to Tools - Next
Actions #8

Updated by okurz 5 months ago

  • Status changed from New to Blocked
  • Assignee set to okurz
Actions #9

Updated by okurz 5 months ago

  • Status changed from Blocked to Resolved
  • Target version changed from Tools - Next to Ready

#138593 should cover that completely. Currently I don't see anything more that needs to be done here.

Actions

Also available in: Atom PDF