794017 - sut_lib.py's setFlag doesn't output failures to the log

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Ed Morley [:emorley]]

Unlike {check.py,clientproxy.py,stop.py}, we don't log.setLevel() in sut_lib.py; so are on the default of warnings and above only.

setFlag() in sut_lib.py uses log.info, so we don't see the messages \o/

Comment 1

[Ed Morley [:emorley]]

Attachment: Make setFlag use log.error

Not sure if we want to set the logging level in the file to INFO as well (currently WARNING; the other sut_tools files use either INFO or DEBUG), but either way, setFlag is used for failures, so log.error() makes sense here regardless.

Comment 2

[Justin Wood (:Callek)]

Comment on attachment 664420 [details] [diff] [review]
Make setFlag use log.error

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

In theory we could/should provide meaningful stuff outside of setFlag anyway, *but* every call to setFlag [for error.flg at least] is certainly an error that we should log as an error, [and currently anything other than error.flg doesn't specify contents in its setFlag call] so fine by me here.

Comment 3

[Ed Morley [:emorley]]

Comment on attachment 664420 [details] [diff] [review]
Make setFlag use log.error

http://hg.mozilla.org/build/tools/rev/034cf22b226f

Comment 4

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley UTC+1] from comment #1)
> Not sure if we want to set the logging level in the file to INFO as well
> (currently WARNING; the other sut_tools files use either INFO or DEBUG)

Will leave this to the patch in bug 781341.

Comment 5

[Justin Wood (:Callek)]

And this is now deployed to production.

Comment 6

[Ed Morley [:emorley]]

Bah, whilst log.error now matches the warning level, it's still not ending up in the log, eg:
https://tbpl.mozilla.org/php/getParsedLog.php?id=15546197&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=15546298&tree=Fx-Team

After discussing on IRC, we should just s/log.error/print/ until the patch in bug 781341 fixes logging properly.

Comment 7

[Ed Morley [:emorley]]

Attachment: Use print rather than log.*

Sorry for the churn on this; just wish there was a way to test these on Try and not have to find out via experimentation :-)

Comment 8

[Ed Morley [:emorley]]

Comment on attachment 664878 [details] [diff] [review]
Use print rather than log.*

http://hg.mozilla.org/build/tools/rev/6cb9a38f124a

(rs+ via IRC)

Comment 9

[Ed Morley [:emorley]]

Callek, I don't suppose you could deploy this for me? :-)

Comment 10

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley UTC+1] from comment #9)
> Callek, I don't suppose you could deploy this for me? :-)

Ping

Comment 11

[Justin Wood (:Callek)]

(In reply to Ed Morley [:edmorley UTC+1] from comment #10)
> (In reply to Ed Morley [:edmorley UTC+1] from comment #9)
> > Callek, I don't suppose you could deploy this for me? :-)
> 
> Ping

Done on foopies 07->35 with:

if [ -z "`hg stat -R /builds/tools --modified`" ]; then hg -R /builds/tools pull -u; fi; exit

none of them had modified files in /builds/tools