coordination #13812
Updated by mkittler about 8 years ago
## Related [use cases](https://progress.opensuse.org/projects/openqav3/wiki/#Use-cases) Especially [UC1](https://progress.opensuse.org/projects/openqav3/wiki/#Use-case-1) and [UC5](https://progress.opensuse.org/projects/openqav3/wiki/#Use-case-5) ## ideas * Failing tests * <del>with unassigned ticket</dev> -> currently implemented implented as [unassigned report](https://w3.nue.suse.com/~okurz/openqa_suse_de_status.html#unassigned_box) * with resolved / closed ticket (also see #12092) * related ticket: #10188 * Consider some testsuites as more important than other testsuites #13780 * Statistics over * failed/passed ratio per build for each product * number of executed testsuites per build for each product * List overall "todo: review" entries * <del>Filter Filter on index page for specific groups</del> -> [gh#923](https://github.com/os-autoinst/openQA/pull/923) groups * Group test results by build number, related ticked: #13742 * Overall status indicator (eg. status light / 'Ampel') * "the oldest still open bug" * "the most flaky scenario / module / architecture" * back-references to bugs * "reverse" carry over: when old job failed and new job passed -> post comment into bug that would have been carried over to new job if it would have failed (related to [okurz wiki](https://wiki.microfocus.net/index.php?title=User:Okurz#Review_of_bugs_.22RESOLVED_FIXED.2C_NOT_VERIFIED.22) ) * scenario result and state change in each tests result * track all changes (eg. infrastructure, test changed, product changed, ...) * measure completion time of builds, also per architecture * finish at least one build per day -> QA reviewer decides this * tests that have not run for long time * live update of bug status (e.g. subscribe a special user to email and trigger events based on email reception) * <del>priority of bugs in review reports</del> -> [openqa_review#25](https://github.com/okurz/openqa_review/pull/25) * personal customized view vs. static hierarchical dashboard view * "weather of scenario", e.g. is it failing all the time or just sporadically * better integration of status from external jobs and testing systems (see [below](#better-integration-of-status-from-external-jobs-and-testing-systems)) ## implementation ideas ### better integration of status from external jobs and testing systems To use openQA also as the main reporting platform relying on other tools we have in our infrastructure (at SUSE) there are already test runners feeding back the information e.g. in junit format. Also, using the client script jobs can be started and their result set along with comments, e.g. for tags. Example: ``` job_id=$(client --host http://localhost jobs post TEST=foo_external _GROUP="openSUSE Tumbleweed AArch64" BUILD=1 | sed -n 's/^{ id => \([0-9]\+\) }$/\1/p') client --host http://localhost jobs/${job_id}/set_done post result=passed client --host http://localhost jobs/${job_id}/comments post text=bsc#1234 ``` ## references could be inspired by sonar, e.g. see https://sonarqube.com/ and https://sonarqube.com/dashboard?id=c-family%3ASamba&did=148, but also [jenkins Radiator View Plugin](https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=69763309) or [jenkins eXtreme Feedback Panel Plugin](https://wiki.jenkins-ci.org/display/JENKINS/eXtreme+Feedback+Panel+Plugin)