When debugging bug 1458480, I wrote a patch to dump the about:support information to the log so I could get some information on what the machine's hardware and runtime configuration was. I think it could be useful to do this by default.

Comment on attachment 8976695 [details] [diff] [review] awsy-about-support.patch Review of attachment 8976695 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for adding this, I can definitely see how it'll be useful. ::: testing/awsy/awsy/test_memory_usage.py @@ +150,5 @@ > self.marionette.switch_to_window(self._tabs[0]) > > + def dump_about_support(self): > + script = """ > + Cu.import("resource://gre/modules/Troubleshoot.jsm"); I'm a little concerned that executing this script and importing Troubleshoot.jsm will impact our startup memory numbers. Perhaps we can move it to `tearDown` instead. I'd also prefer for it to be output to a verbose level, at least when running locally.

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #1) > Comment on attachment 8976695 [details] [diff] [review] > awsy-about-support.patch > > Review of attachment 8976695 [details] [diff] [review]: > ----------------------------------------------------------------- > > Thanks for adding this, I can definitely see how it'll be useful. > > ::: testing/awsy/awsy/test_memory_usage.py > @@ +150,5 @@ > > self.marionette.switch_to_window(self._tabs[0]) > > > > + def dump_about_support(self): > > + script = """ > > + Cu.import("resource://gre/modules/Troubleshoot.jsm"); > > I'm a little concerned that executing this script and importing > Troubleshoot.jsm will impact our startup memory numbers. Perhaps we can move > it to `tearDown` instead. I'd also prefer for it to be output to a verbose > level, at least when running locally. Ah, yes I agree moving this to tearDown would be much safer. I'll do that. As for the logging level, by verbose level do you mean level.DEBUG? I don't see a verbose level in mozlog [1]. If it's at level.DEBUG will it output by default in taskcluster? I really only care about being able to see this without having to resend out a try run, I don't mind it being hidden by default locally. [1] https://firefox-source-docs.mozilla.org/mozbase/mozlog.html#data-format

(In reply to Ryan Hunt [:rhunt] from comment #2) > (In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment > #1) > > Comment on attachment 8976695 [details] [diff] [review] > > awsy-about-support.patch > > > > Review of attachment 8976695 [details] [diff] [review]: > > ----------------------------------------------------------------- > > > > Thanks for adding this, I can definitely see how it'll be useful. > > > > ::: testing/awsy/awsy/test_memory_usage.py > > @@ +150,5 @@ > > > self.marionette.switch_to_window(self._tabs[0]) > > > > > > + def dump_about_support(self): > > > + script = """ > > > + Cu.import("resource://gre/modules/Troubleshoot.jsm"); > > > > I'm a little concerned that executing this script and importing > > Troubleshoot.jsm will impact our startup memory numbers. Perhaps we can move > > it to `tearDown` instead. I'd also prefer for it to be output to a verbose > > level, at least when running locally. > > Ah, yes I agree moving this to tearDown would be much safer. I'll do that. > > As for the logging level, by verbose level do you mean level.DEBUG? I don't > see > a verbose level in mozlog [1]. Yes, DEBUG is equivalent to what I was thinking. > If it's at level.DEBUG will it output by default in taskcluster? I really > only > care about being able to see this without having to resend out a try run, I > don't mind it being hidden by default locally. > > [1] https://firefox-source-docs.mozilla.org/mozbase/mozlog.html#data-format I *think* it will show up. I'm not an expert on taskcluster and logging, I guess the best option is to push a test using the debug level. If it captures the output I'd expect it to show up under "Job Details" as an artifact, either in "awsy_raw.log" or "awsy_debug.log". If that doesn't work, :bc might be able to help us out.

From looking at a couple try runs I don't see an awsy_debug.log, there is a log.raw but I can't see any debug output. I did one try run a while back with this debug output as well and couldn't find the output anywhere. :bc is there a log level that will only output in infrastructure? Or any equivalent way of just not logging something locally, but logging it on try.

The only way I know of doing it at the moment would be to add an argument cmd.append("--log-raw-level=debug") to your try push at: https://searchfox.org/mozilla-central/source/testing/mozharness/scripts/awsy_script.py#166 gbrown: I'm sure you have a better suggestion.

Sorry, I don't have a better suggestion. Adding an argument in awsy_script.py should be an effective way of adding logging on try without affecting local runs; however, awsy runs on other trees (mozilla-central, etc) would also be affected -- hopefully that's okay? I think it would be tricky to provide special logging only on try (maybe by manipulating --extra-options in the taskcluster yml...but I think there's no easy way of restricting that to try).

(In reply to Geoff Brown [:gbrown] from comment #6) > Sorry, I don't have a better suggestion. > > Adding an argument in awsy_script.py should be an effective way of adding > logging on try without affecting local runs; however, awsy runs on other > trees (mozilla-central, etc) would also be affected -- hopefully that's > okay? I think it would be tricky to provide special logging only on try > (maybe by manipulating --extra-options in the taskcluster yml...but I think > there's no easy way of restricting that to try). All automation is fine.

(In reply to Bob Clary [:bc:] from comment #5) > The only way I know of doing it at the moment would be to add an argument > cmd.append("--log-raw-level=debug") to your try push at: > > https://searchfox.org/mozilla-central/source/testing/mozharness/scripts/ > awsy_script.py#166 > > gbrown: I'm sure you have a better suggestion. Ah, my bad, I meant to say have it logged on all infrastructure/taskcluster runs not just try. That sounds reasonable though, I'll do a test run to see if lowering the log-raw-level causes it to increase in size too much.