action #124991
coordination #102915: [saga][epic] Automated classification of failures
QA - coordination #94105: [epic] Use feedback from openqa-investigate to automatically inform on github pull requests, open tickets, weed out automatically failed tests
Copy ids of other investigate jobs to retry job
0%
Description
Motivation¶
See parent #109920.
We want to check that all investigation jobs of a failed job have finished, so we need to find out the ids of the other investigate jobs.
One solution is to save the ids in one of the investigation job.
So we create the investigation jobs for last_good_tests, last_good_build, last_good_tests_and_build, and save the job ids.
Then we create the simple retry job and add a setting to it: OTHER_INVESTIGATE_JOBS=id1,id2,id3
We choose this job because it is always created, the other investigation jobs might not always be created.
Acceptance criteria¶
- AC1: The retry job has a setting mentioning the other investion job ids
Suggestions¶
- This task is already complex enough for its own ticket. Getting back the id of the cloned job is not trivial, because we are using the output of the
clone
function already. - Move down the creation of the retry job to be the last
clone
- One solution is to create a partially global variable that is set by the
clone
function. This stops working as soon as theclone
function is called as a subprocess, e.g.$(clone ...)
- This could actually be made nicer by also moving the output of the clone function to such a helper variable. Of course we still would want to catch stderr sometimes. Needs thinking
- Consider turning this into a perl script :]
Related issues
History
#1
Updated by tinita 3 months ago
- Copied from action #109920: Identify reproducible product issues using openqa-investigate size:M added
#4
Updated by okurz 3 months ago
- Category deleted (
Feature requests) - Priority changed from High to Low
What we discussed in the unblock: The ticket in the current way is not describing a useful user story but an implementation detail. If possible a better way would be to create a timeboxed spike solution for #109920 how to go forward, if with the approach mentioned here or the "Suggestion 2" from the parent or even a different approach.
#5
Updated by okurz about 2 months ago
- Category set to Feature requests
#6
Updated by okurz about 1 month ago
- Status changed from New to Rejected
- Assignee set to okurz
Discussed in the estimation meeting 2023-04-27 and we understood #126527#note-9 in a way that we don't need this.
#7
Updated by okurz about 1 month ago
- Parent task changed from #109920 to #94105