action #121429
closed[qe-tools] qe-review bot sends wrong notification even the issue got fixed and the test case failed on different place size:M
Description
Observation¶
see #119416
I think it should be checked for different places, not simply take the record in the past.
Acceptance criteria¶
- AC1: Expected behavior is known
- AC2: The correct notifications are sent
Suggestions¶
- Confirm why it took a week between the job result and the reminder comment
- Verify if these are unrelated issues and why they're still associated
- Talk to the OP
Updated by zluo about 2 years ago
- Project changed from openQA Tests (public) to openQA Project (public)
- Start date deleted (
2022-12-05)
Updated by okurz about 2 years ago
- Category set to Support
- Target version set to Ready
Updated by livdywan about 2 years ago
- Subject changed from [qe-tools] qe-review bot sends wrong notification even the issue got fixed and the test case failed on different place to [qe-tools] qe-review bot sends wrong notification even the issue got fixed and the test case failed on different place size:M
- Description updated (diff)
- Status changed from New to Workable
Updated by okurz about 2 years ago
- Related to action #19222: [discussion] Improve automatic carryover to be more strict - when bugs relate to individual steps within test details added
Updated by okurz about 2 years ago
- Status changed from Workable to Resolved
- Assignee set to okurz
@zluo https://openqa.suse.de/tests/10028274#comments shows
rfan1 wrote 2022-11-24 15:04:32 +0000
poo#119416
(Automatic takeover from t#9757679)
And if we follow that link to the original job we find https://openqa.suse.de/tests/9757679#comment-655578 stating
rfan1 wrote 2022-10-26 07:07:01 +0000
poo#119416
and it's correct that https://openqa.suse.de/tests/10028274#step/vnc_two_passwords/29 looks like a different cause. But the openQA label carry over can only decide on the failed module, not the test step. We do not plan to change that because that would mean that tests that are showing more steps depending on timing behaviour would prevent a carry-over. Also see #19222#note-2 and following points as reasoning. So I have to resolve this ticket with the explanation: "everything works as expected". Sorry about that. I can only recommend if you find such cases then carefully review the job failure and update ticket references accordingly.