coordination #13812
Updated by okurz over 6 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 * <del>Failing tests</del> Failing tests * <del>with unassigned ticket</del> ticket</dev> -> currently implemented as [unassigned report](https://w3.nue.suse.com/~okurz/openqa_suse_de_status.html#unassigned_box) * <del>with with resolved / closed ticket</del> ticket (also see #12092) * <del>related ticket:</del> related ticket: #10188 * <del>Consider Consider some testsuites as more important than other testsuites</del> testsuites #13780 * <del>Filter on index page for specific groups</del> -> [gh#923](https://github.com/os-autoinst/openQA/pull/923) * <del>Group test results by build number, related ticked:</del> #13742 * <del>finish at least one build per day -> Current workflow: QA reviewer decides this and can mark one build as important, feature request</del> #15844 * <del>priority of bugs in review reports</del> -> [openqa_review#25](https://github.com/okurz/openqa_review/pull/25) * <del>on index page add link to filter box (down) because "no one scrolls down"</del> -> https://gitlab.suse.de/openqa/salt-states-openqa/merge_requests/19 * <del>"milestones" as special tags (asked by ast)</del> -> http://open.qa/docs/#_tag_builds_with_special_comments_on_group_overview * <del>special mode of Dashboard mode which allow to see summary of all job groups in optimized to full screen view</del> #17886 * 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 on index page for specific groups</del> -> [gh#923](https://github.com/os-autoinst/openQA/pull/923) * <del>Group test results by build number, related ticked: #13742</del> * 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 -> Current workflow: QA reviewer decides this and can mark one build as important, feature request #15844 * 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)) * customized, personal filter pre-saved * on index page add link to filter box (down) because "no one scrolls down" * "milestones" as special tags (asked by ast) * dheidler: learn about bugzilla integration in "smash" (e.g. ask tgoettlicher) * special mode of Dashboard mode which allow to see summary of all job groups in optimized to full screen view #17886 * acceptance criteria * main page have a switcher which allow to switch between "normal" and "fullscreen" dashboard representations * "fullscreen" use same filter settings as "normal" * there is configurable auto-refresh for "fullscreen" mode ## 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) or https://jenkins.io/blog/2016/01/10/beautiful-jenkins-dashboard/ … or https://github.com/influxdata/chronograf And don't forget about http://testsuites.qa.suse.cz