action #91773
closed
QA (public) - coordination #91646: [saga][epic] SUSE Maintenance QA workflows with fully automated testing, approval and release
coordination #89062: [epic] Simplify review for SUSE QAM
Automatic replacement of openQA job URLs preview of openQA size:M
Added by okurz almost 4 years ago.
Updated over 3 years ago.
Category:
Feature requests
Description
Motivation¶
openqa-investigate provides comments in openQA jobs. To see the results one needs to follow the URLs. An immediate overview could be achieved if openQA could automatically replace openQA job URLs when displaying by a status display, e.g. the green/yellow/red bubble icon same as we have in /tests, /tests/overview, the "next & previous" job list, etc.
Acceptance criteria¶
- AC1: Whenever openQA job URLs are rendered in an openQA instance the according job status is visible on the same page
- AC2: Feature switch exists
Out of scope¶
Suggestions¶
- Assuming we already render comments asynchronously I think putting in the job status whenever we render an openQA job url should be ok performance-wise.
- As I am talking about putting the job status within the text comment that could be either just text, like "(passed)", "(soft-failed)" or maybe also nice colored unicode symbols :)
- Add a feature switch that we can disable on performance problems
- Related to coordination #94105: [epic] Use feedback from openqa-investigate to automatically inform on github pull requests, open tickets, weed out automatically failed tests added
- Target version changed from future to Ready
- Subject changed from Automatic replacement of openQA job URLs preview of openQA to Automatic replacement of openQA job URLs preview of openQA size:M
- Description updated (diff)
- Status changed from New to Workable
In the meeting we said a client-side solution would be difficult because we needed to replace the URLs after the overall page has loaded and doing so would be disturbing as it affects the layout. However, it could be implemented in a way that before the job status is known a loading circle is rendered which is replaced by a status circle of the same size when the status is known and the job's name would only be added as tooltip. The link text could be folded to "job#1234" from the beginning. This way the layout would not change suddenly.
mkittler wrote:
In the meeting we said a client-side solution would be difficult because we needed to replace the URLs after the overall page has loaded and doing so would be disturbing as it affects the layout. However, it could be implemented in a way that before the job status is known a loading circle is rendered which is replaced by a status circle of the same size when the status is known and the job's name would only be added as tooltip. The link text could be folded to "job#1234" from the beginning. This way the layout would not change suddenly.
So rather than 🔴kde-wayland@aarch64 it would be 🔴job#1868683?
If we decide we can't render the name I would rather stick to the URL since job#
is not a common way to refer to jobs. So it would be 🔴https://openqa.opensuse.org/tests/1868683.
That said I'd strongly prefer rendering the name somehow. We could show empty comments until we have the job names (or time out and show it verbatim).
cdywan wrote:
[…]
If we decide we can't render the name I would rather stick to the URL since job#
is not a common way to refer to jobs. So it would be 🔴https://openqa.opensuse.org/tests/1868683.
That said I'd strongly prefer rendering the name somehow.
Why care about the name? I think only the job result is important for now. That should make implementation easier.
We could show empty comments until we have the job names (or time out and show it verbatim).
Why not just add the job status icon after the URL whenever we managed to receive that data?
- Status changed from Workable to In Progress
- Assignee set to tinita
I think I found another bug.
The activity view is supposed to poll jobs which are not yet finished and display the updated status.
However, the code
https://github.com/os-autoinst/openQA/blob/master/assets/javascripts/openqa.js#L377
// continue polling for job state updates until the job state is done
if (job.state !== 'done') {
setTimeout(updateTestState, 5000);
}
Does not pass any arguments to updateTestState
.
If I change it to
// continue polling for job state updates until the job state is done
if (job.state !== 'done') {
setTimeout(function() { updateTestState(job, name, timeago, reason) }, 5000);
}
Then it calls the function repeatly, but that doesn't do the http request.
- Related to action #95746: Identify likely "sporadic" openQA tests with "openqa-investigate" size:M added
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
Also available in: Atom
PDF