Uploaded image for project: 'Qt Quality Assurance Infrastructure'
  1. Qt Quality Assurance Infrastructure
  2. QTQAINFRA-5168

jira ticket automation script (mapping)

    XMLWordPrintable

Details

    • Task
    • Resolution: Unresolved
    • Not Evaluated
    • None
    • None
    • None

    Description

      The goal of the script is to create Jira bugs automatically.

      The script should be usable for for both blacklisted and flaky test cases.
      The Jira connection part of the script is already done - and based on another project:
      https://git.qt.io/kaabdelr/insignificant-bot
      The important part of the script was providing correct Jira component names relevant to the reported test.
      Insignificant-bot scrip, which functionality we used, provided an ML approach.
      When we tested it - it provided only 20% of matches, that's why we decided to create mapping functionality.
      Additional arguments to provide mapping was - ML models are trained on already existing data - when checking Jira history there was lots of inconsistencies in categorizing tests (the same tests had different component names, for various reasons). Another argument - the Jira component list is dynamic, and some components are removed new ones are added. The model was not general enough to allow proper categorization for not yet covered tests.

      Map:
      The map should be in the form key->value, where:
      key is list of keywords eg. ['gui', 'painting'] or ['gui', 'widet', 'layout'] (the lists are or different lengths but usually 2 or 3 elements)
      value is jira compoment (eg 'GUI:Painting')
      example for test at a path:
      ./gui/painting/qpainter/tst_qpainter.cpp
      key: gui, painting, qpainter
      value: 'GUI: Painting'
      map entry:
      (gui, painting, painter):'GUI: Painting'

      project repo containing: keywords, and responses from maintainers is available at:
      https://git.qt.io/qtqa/jira_test_report_bot

      Duplicate handling:
      We run Jira queries to check if the report for a given test was created in the last 2 months. If the report in past exists, regardless of status, creating new report is aborted

      During a meeting with Alex Blasche we agreed to those points:
      5 reports per week (top 5 tests including possible repetitions)
      each report has P2 priority
      we check history up to 2 months for repeating a report
      the jira report body should have links to log and or possibly body of failure
      bot should connect to jira using OAuthth (contact Daniel Smith)
      create testmetrics bot on real jira and get access
      when setup is ready - send email to whole qt developers including opensource
      add a wiki page accessible externally (not just internally)
      inform developers about results and statistics : how many tests were successfully fixed, how many were blacklisted, and how many are still failing

      During a meeting with Axel Spoerl we agreed to
      change the body of the report to add information about blocked gerrit changes: (for qtbase project: single fail blocks around 5 gerrit changes, since qtbase changes are usually grouped, while other project are integrated separately (1 integration = 1 gerrit change)
      change counting from flaky/failed per flaky/filed per function to avoid duplicates (developers were grouping tickets covering different platforms to 1 report per test function)
      exclude early warning integrations from builds
      implement log analysis: so far we were providing excerpt from log for a last failure. We can check if given test failed consistently for some reason, or the failure points and reasons vary. This analysis can be done using our internal scripts that parse logs. The result of analysis can be added as attachment to a report.

      update qtbase
      update qt declarative mapping from Mitch
      + check stats per platform (outliers)
      + update script to pull data from SQL database, rather than influx

      Future notes:

      • providing grouping mechanism for similar platforms (eg MacOS family)
      • add mechanism to update changes in tests structures / new components

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              anwojcie Anna Wojciechowska
              anwojcie Anna Wojciechowska
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There are no open Gerrit changes