Project

General

Profile

Actions

action #95989

closed

openqa-review gitlab CI pipeline jobs fail with "AttributeError: 'NoneType' object has no attribute 'group'"

Added by okurz over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Target version:
Start date:
2021-07-26
Due date:
% Done:

0%

Estimated time:

Description

Observation

https://gitlab.suse.de/openqa/openqa-review/-/jobs/507143 and others:

Traceback (most recent call last):
  File "/usr/bin/openqa-review", line 33, in <module>
    sys.exit(load_entry_point('openqa-review==0.0.0', 'console_scripts', 'openqa-review')())
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 1555, in main
    report = generate_report(args)
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 1486, in generate_report
    return Report(browser, args, root_url, job_groups)
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 1435, in __init__
    self.report[k] = self._one_report(v)
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 1446, in _one_report
    return ProductReport(self.browser, job_group_url, self.root_url, self.args)
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 1159, in __init__
    results = get_arch_state_results(arch, current_details, previous_details, args.output_state_results)
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 315, in get_arch_state_results
    states = SortedDict(get_state(v, test_results_previous_dict) for k, v in test_results_dict.items())
  File "/usr/lib/python3.8/site-packages/sortedcontainers/sorteddict.py", line 186, in __init__
    self._update(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/sortedcontainers/sorteddict.py", line 559, in update
    dict.update(self, *args, **kwargs)
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 315, in <genexpr>
    states = SortedDict(get_state(v, test_results_previous_dict) for k, v in test_results_dict.items())
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 302, in get_state
    state_dict.update(get_test_bugref(cur))
  File "/usr/lib/python3.8/site-packages/openqa_review/openqa_review.py", line 286, in get_test_bugref
    return {"bugref": re.search(r"\S+#([0-9]+)", bugref.i["title"]).group(), "bugref_href": bugref.a["href"].strip()}
AttributeError: 'NoneType' object has no attribute 'group'
+ save_report=

Suggestions

Would be nice if the last report could be kept and not lost on errors


Related issues 1 (0 open1 closed)

Related to QA - action #96350: Improve openqa-review generation: Add date to index size:SResolvedjbaier_cz

Actions
Actions #1

Updated by tinita over 2 years ago

  • Status changed from New to In Progress
  • Assignee set to tinita
Actions #2

Updated by tinita over 2 years ago

  • Status changed from In Progress to Feedback
Actions #3

Updated by tinita over 2 years ago

Actions #4

Updated by tinita over 2 years ago

  • Status changed from Feedback to Resolved

pipeline successful

Actions #5

Updated by okurz over 2 years ago

  • Status changed from Resolved to Feedback

please consider from our https://progress.opensuse.org/projects/qa/wiki/Wiki#Definition-of-DONE : "For regressions: A regression fix is provided, flaws in the design, monitoring, process have been considered". Also https://progress.opensuse.org/projects/qa/wiki/Wiki#How-we-work-on-our-backlog mentions: "For every regression or bigger issue that we encounter try to come up with at least two improvements, e.g. the actual issue is fixed and similar cases are prevented in the future with better tests and optionally also monitoring is improved" and "For critical issues and very big problems collect "lessons learned", e.g. in notes in the ticket or a meeting with minutes in the ticket, consider https://en.wikipedia.org/wiki/Five_whys and answer at least the following questions: "User impact, outwards-facing communication and mitigation, upstream improvement ideas, Why did the issue appear, can we reduce our detection time, can we prevent similar issues in the future, what can we improve technically, what can we improve in our processes". Also see https://youtu.be/_Dv4M39Arec"

Actions #6

Updated by tinita over 2 years ago

@okurz I don't get what you mean, can you help me?

Actions #7

Updated by okurz over 2 years ago

We decided as a team e.g. in #91674 that we can find more than just a single fix whenever we encounter issues. So we – as a team, does not need to be you all alone – should try to brainstorm and understand how this problem happened, how it could have been prevented, if we need to introduce more checks, better design, monitoring&alerts, different process, etc. I am happy to explain in a video chat as well if you prefer. This topic could be worthwhile to discuss e.g. tomorrow in the daily meeting or on Friday in the weekly.

Actions #8

Updated by okurz over 2 years ago

Ideas from weekly:

  • Add a date on the index page when reports were generated
  • If individual reports can not be generated, mention that as well with an explicit message
  • Try to preserve old reports if individual new ones can not be generated
  • If we know of an issue with a ticket point to the ticket for users to follow
  • Maybe we are a bit unfamiliar with complex gitlab CI pipelines

@tinita to create follow-up tasks

Actions #9

Updated by tinita over 2 years ago

  • Related to action #96350: Improve openqa-review generation: Add date to index size:S added
Actions #10

Updated by tinita over 2 years ago

okurz wrote:

  • If we know of an issue with a ticket point to the ticket for users to follow

I don't understand that one.

Actions #11

Updated by okurz over 2 years ago

  • Status changed from Feedback to Resolved

what I meant with "If we know of an issue with a ticket point to the ticket for users to follow": In openqa-review reports rather than printing an error or a warning in the log file which nobody will see or care about we should rather generate a line in the report directly telling what the issue about the particular openQA job was, e.g. if a bug URL was used that is not understood. Similar to what I suggested in https://github.com/os-autoinst/openqa_review/pull/173#discussion_r676465447
But I will resolve the ticket. I think it's ok how we handled it for now.

Actions

Also available in: Atom PDF