All users were logged out of Bugzilla on October 13th, 2018

Make sut_tools/verify.py output failures in the format "Automation Error: " so TBPL's parser recognises them

RESOLVED FIXED

Status

RESOLVED FIXED
6 years ago
5 months ago

People

(Reporter: emorley, Assigned: emorley)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sheriff-want])

Attachments

(1 attachment, 1 obsolete attachment)

5.27 KB, patch
jmaher
: review+
emorley
: checked-in+
Details | Diff | Splinter Review
(Assignee)

Description

6 years ago
(Bah, I should have done this as part of bug 787019)

Failures of the type bug 781419 require the log to be opened, since TBPL doesn't recognise the error string and so doesn't show it in the annotated summary box.

We can either change the string to match one of the ones at:
http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/file/b3f9daa143ce/php/inc/GeneralErrorFilter.php#l24

Or add our own, after changing from 'WARNING: ' since that's too generic & will match against other parts of the log.

I suggest changing:
WARNING: Unable to ping tegra after 5 attempts
to (the already recognised):
Automation Error: Unable to ping tegra after 5 attempts

(Whilst we're at it, we might as well change other error strings in verify.py at the same time).
(Assignee)

Updated

6 years ago
Assignee: nobody → bmo
Status: NEW → ASSIGNED
(Assignee)

Comment 1

6 years ago
installApp.py uses a lot of:
"Remote Device Error: foo"
...perhaps we should add that to the parser in addition to "Automation Error: " ?
(Assignee)

Comment 2

6 years ago
Created attachment 660415 [details] [diff] [review]
Patch v1

Prefixes a number of failures with "Automation Error:" or "Remote Device Error:" so TBPL's parser can recognise them.

The "Remote Device Error:" case will require a TBPL change, I'll file that now.

Had to make best guess as to which errors to put under which category, tweaks welcome :-)
Attachment #660415 - Flags: review?(bugspam.Callek)
(Assignee)

Updated

6 years ago
Depends on: 790618
(Assignee)

Updated

6 years ago
Depends on: 781341
Comment on attachment 660415 [details] [diff] [review]
Patch v1

From a releng perspective just changing these strings are fine.

Add'l r? to jmaher since he has code that this will bitrot, and for the determination of which strings are correct.
Attachment #660415 - Flags: review?(jmaher)
Attachment #660415 - Flags: review?(bugspam.Callek)
Attachment #660415 - Flags: review+
Comment on attachment 660415 [details] [diff] [review]
Patch v1

Review of attachment 660415 [details] [diff] [review]:
-----------------------------------------------------------------

r- because I am concerned about the error for all cases when we are not installing robocop.apk.

This is from a jsreftest log on m-c:
return code [0]
$>
WARNING (robocop): zip file not as expected: There is no item named 'bin/robocop.apk' in the archive (("There is no item named 'bin/robocop.apk' in the archive",))
WARNING (robocop): robocop.apk will not be installed
/builds/sut_tools/installApp.py:84: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  print "WARNING (robocop): zip file not as expected: %s (%s)" % (e.message,
program finished with exit code 0
elapsedTime=122.863866
========= Finished Install App on Device (results: 0, elapsed: 2 mins, 2 secs) (at 2012-09-12 14:32:14.329316) =========

::: sut_tools/installApp.py
@@ +85,2 @@
>                                                                          str(e.args))
> +                print "Remote Device Error: (robocop) robocop.apk will not be installed"

these are not really remote device errors, they would be 'Automation Error'

@@ +89,2 @@
>                                                                        str(matches))
> +            print "Remote Device Error: (robocop) robocop.apk will not be installed"

Won't this occur when we are testing without robocop.apk?  This really seems problematic.
Attachment #660415 - Flags: review?(jmaher) → review-
(Assignee)

Comment 5

6 years ago
Created attachment 660890 [details] [diff] [review]
Patch v2

As before except without the changes to the robocop.apk warnings (I had forgotten we indiscriminately display that warning in non-robocop runs).

Those strings weren't the ones I was most fussed about anyway; the bug 781419 case is the primary goal - I was just trying to do some others whilst I was there :-)
Attachment #660415 - Attachment is obsolete: true
Attachment #660890 - Flags: review?(jmaher)
Comment on attachment 660890 [details] [diff] [review]
Patch v2

Review of attachment 660890 [details] [diff] [review]:
-----------------------------------------------------------------

this looks pretty good.
Attachment #660890 - Flags: review?(jmaher) → review+
Blocks: 791477
(In reply to Ed Morley (Away 18th-20th) [:edmorley UTC+1] from comment #7)
> Comment on attachment 660890 [details] [diff] [review]
> Patch v2
> 
> Thank you :-)
> 
> http://hg.mozilla.org/build/tools/rev/709ef2c85ac7

Deployed to all foopies just now.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 9

6 years ago
(In reply to Justin Wood (:Callek) from comment #8)
> Deployed to all foopies just now.

Thank you, working great on TBPL now :-)
(Assignee)

Updated

6 years ago
No longer depends on: 781341
Product: mozilla.org → Release Engineering
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.