Project

General

Profile

action #13242

WDYT: For every job that does not have a label or bugref, retrigger some times to see if it's sporadic. Like rescheduling on incomplete but on failed

Added by okurz over 6 years ago. Updated about 3 years ago.

Status:
Rejected
Priority:
Low
Assignee:
Category:
Feature requests
Target version:
Start date:
2016-11-25
Due date:
% Done:

0%

Estimated time:
Difficulty:

Related issues

Related to openQA Project - coordination #39719: [saga][epic] Detection of "known failures" for stable tests, easy test results review and easy tracking of known issuesResolved2018-05-23

Related to openQA Project - action #9966: Be more robust about spurious errorsNew2015-12-18

Follows openQA Project - coordination #14972: [tools][epic] Improvements on backend to improve better handling of stallsResolved2016-11-24

History

#1 Updated by okurz over 6 years ago

  • Project changed from openQA Tests to openQA Project

#2 Updated by coolo over 6 years ago

the main problem with the automatic retriggering was (and will be) about the reporting - you hardly know if a running job is running for the first time or not and why it was restarted. Of course you'll see in the job if looking at it - but if you have 80 running jobs and 300 scheduled, you'll hardly notice.

The jobs I retrigger the most are actually the ones that are labeled ;(

#3 Updated by szarate about 6 years ago

  • Follows coordination #14972: [tools][epic] Improvements on backend to improve better handling of stalls added

#4 Updated by okurz about 6 years ago

  • Category set to Feature requests

#5 Updated by coolo over 5 years ago

  • Priority changed from Normal to Low
  • Target version set to future

What we'd need is a complete new handling of jobs including groups of them and such. Everything else requires external triggering/monitoring. 90% reject for me

#6 Updated by okurz almost 5 years ago

  • Target version changed from future to future

#7 Updated by okurz over 4 years ago

  • Related to coordination #39719: [saga][epic] Detection of "known failures" for stable tests, easy test results review and easy tracking of known issues added

#8 Updated by okurz about 3 years ago

  • Related to action #9966: Be more robust about spurious errors added

#9 Updated by okurz about 3 years ago

  • Status changed from New to Rejected
  • Assignee set to okurz

The problem mentioned in #13242#note-2 is meanwhile fixed by the definition of a "scenario" and its history. The rest is for #9966 where I added the proposal of this ticket.

Also available in: Atom PDF