Only highlight the effective bugref(s) in the comments

[kalikiana]

The latest comment with one or more bugrefs is considered for takeover. Others are effectively ignored. This should be clearly visible in the web UI.

[github-actions[bot]]

Great PR! Please pay attention to the following items before merging:

Files matching assets/stylesheets/**:

• [ ] Consider providing screenshots in a PR comment to show the difference visually

This is an automatically generated QA checklist based on modified files

[okurz]

Nice idea. Please double check that this is really the current behavior, not that we have wrong expectations on what actually happens

[Martchus]

It would be nice if the other labels would still be formatted but e.g. just be grayed out (instead of having the yellow background).

[kalikiana]

It would be nice if the other labels would still be formatted but e.g. just be grayed out (instead of having the yellow background).

I realized takeover looks for the most recent bugref. It doesn't care about labels and doesn't use this CSS class. So I changed it to actually add a new class openqa-bugref and make the bugref bold if it's the latest one, in addition to clarifying the docs.

[Martchus]

Ok, I suppose that's good. However, it looks like tests needed to be adjusted.

[codecov[bot]]

Codecov Report

Merging #4717 (cb2b835) into master (1cfa3f7) will decrease coverage by 0.00%. The diff coverage is 100.00%.

:exclamation: Current head cb2b835 differs from pull request most recent head 0cfdda6. Consider uploading reports for the commit 0cfdda6 to get more accurate results

@@            Coverage Diff             @@
##           master    #4717      +/-   ##
==========================================
- Coverage   98.08%   98.08%   -0.01%     
==========================================
  Files         375      375              
  Lines       34783    34776       -7     
==========================================
- Hits        34117    34110       -7     
  Misses        666      666              

Impacted Files	Coverage Δ
lib/OpenQA/Utils.pm	99.52% <100.00%> (ø)
t/16-utils.t	100.00% <100.00%> (ø)
lib/OpenQA/Worker/WebUIConnection.pm	94.55% <0.00%> (-0.03%)	:arrow_down:
t/24-worker-overall.t	100.00% <0.00%> (ø)
t/ui/28-keys_to_render_as_links.t	100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[okurz]

please follow https://github.com/os-autoinst/openQA/pull/4717#issuecomment-1164110960, i.e. screenshot please :)

[kalikiana]

please follow #4717 (comment), i.e. screenshot please :)

To add context to my requesting re-review. I'm not posting a screenshot so long as it doesn't work as we expect. But I need someone to spot the mistake in either the CSS or the Perl code.

EDIT: I guess this still isn't resetting approvals.

[Martchus]

Ah, then I'll try it out locally.

[Martchus]

I've been pushing an additional commit that should fix it.

It also works when comments are removed or newly created. However, when editing a commit it doesn't work until one reloads the page because comments are not reordered on the fly when editing.

[Martchus]

It looks like the carry over algorithm goes by the comment creation (as it looks for comments with the highest ID first) and the sorting of comments on the page also goes by creation (renders comments with lower IDs first via __PACKAGE__->has_many(comments => 'OpenQA::Schema::Result::Comments', 'job_id', {order_by => 'id'});). However, when I've just tested it locally, the comments are sorted by the last edit. That's likely a bug (which should be fixed independently).

Created #4759 to fix the sorting behavior.

[okurz]

@Mergifyio rebase

[mergify[bot]]

rebase

✅ Branch has been successfully rebased

[mergify[bot]]

This pull request is now in conflicts. Could you fix it? 🙏