action #103317
closed
No time visible in scheduled jobs
Added by livdywan over 2 years ago.
Updated about 2 years ago.
Category:
Feature requests
Description
Observation¶
I'm cloning several jobs, which are run within a few minutes. The next job is sitting there longer, for example 30 minutes, but I can't tell from the job details so long as it's in the "scheduled" state. See also the attached screenshot.
Results for opensuse-Tumbleweed-NET-x86_64-Build20211129-textmode@64bit
State: scheduled
Scheduled product: job has not been created by posting an ISO
50
Installation in textmode and selecting the textmode "desktop" during installation.
Note: The activity also doesn't show the time for scheduled jobs.
Work-around¶
- Use the "All tests" view.
- Type e.g.
Build20211129 in the filter view of "scheduled" tests
Files
- Category set to Feature requests
- Priority changed from Normal to Low
- Target version set to Ready
so you would want something equivalent to the "running, started X minutes ago", like "scheduled, waiting since X minutes"?
okurz wrote:
so you would want something equivalent to the "running, started X minutes ago", like "scheduled, waiting since X minutes"?
Yeah. On "All tests" the table header says "Created" so maybe "scheduled, created X minutes ago" would be consistent. Although I'd slightly prefer "scheduled X minutes ago" and rename the table header.
- Target version changed from Ready to future
Proposal sounds good. Sorry, wanted to put this into future. As this is not critical we should not immediately pick up newer reports over older ones that still wait.
I think this functionality will ease detection of freeze jobs . +1
very useful feature!
Can we also show how many jobs is in backlog now (not schedule yet) or how long it will wait for run.
BTW: if we can adjust priority automatic in case waiting too long?
coolgw wrote:
Can we also show how many jobs is in backlog now (not schedule yet)
good idea. I envision a message like `scheduled (since about 2 hours, 1234 jobs in the queue for the same worker class)
or how long it will wait for run.
Well, we can't give a guarantee but we could estimate how long it took for jobs in the same worker class in the past
BTW: if we can adjust priority automatic in case waiting too long?
well, that depends on what is "too long" and how to adjust priorities. Currently we use AFAIK a prioritized FIFO queue, i.e. as long as there are no jobs with higher priority in the same worker class then the oldest one will be executed first. How would you expect an automatic priority change impact that?
- Assignee deleted (
mkittler)
- Status changed from New to Resolved
- Assignee set to mkittler
I added the not yet implemented part to #65271 so that we can conclude the part about scheduled time here. Trying to keep it both in the same ticket could be cause more confusion than it would help.
Also available in: Atom
PDF
