Actions
action #13242
closedWDYT: 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
Start date:
2016-11-25
Due date:
% Done:
0%
Estimated time:
Updated by okurz over 7 years ago
- Project changed from openQA Tests to openQA Project
Updated by coolo over 7 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 ;(
Updated by szarate over 7 years ago
- Follows coordination #14972: [tools][epic] Improvements on backend to improve better handling of stalls added
Updated by coolo over 6 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
Updated by okurz almost 6 years ago
- Target version changed from future to future
Updated by okurz over 5 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
Updated by okurz over 4 years ago
- Related to coordination #9966: [epic] Be more robust about spurious errors added
Updated by okurz over 4 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.
Actions