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 3 years ago. Updated about 1 month ago.

Status:RejectedStart date:25/11/2016
Priority:LowDue date:
Assignee:okurz% Done:

0%

Category:Feature requests
Target version:QA - future
Difficulty:
Duration:

Related issues

Related to openQA Project - action #39719: [epic] Detect "known failures" and mark jobs as such Blocked 23/05/2018 31/12/2020
Related to openQA Project - action #9966: Be more robust about spurious errors New 18/12/2015
Follows openQA Project - action #14972: [tools][epic] Improvements on backend to improve better h... New 24/11/2016

History

#1 Updated by okurz over 3 years ago

  • Project changed from openQA Tests to openQA Project

#2 Updated by coolo over 3 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 3 years ago

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

#4 Updated by okurz about 3 years ago

  • Category set to Feature requests

#5 Updated by coolo over 2 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 over 1 year ago

  • Target version changed from future to future

#7 Updated by okurz over 1 year ago

  • Related to action #39719: [epic] Detect "known failures" and mark jobs as such added

#8 Updated by okurz about 1 month ago

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

#9 Updated by okurz about 1 month 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