mozilla :: #ateam

14 Jul 2017
08:31Standard8Does anyone know if theres a discussion / bug about try showing tests that are still in-development getting green?
10:28mikedeboerWho would be able to review the patches in bug 1380470 for me? They implement add_task().skip() and add_task().only() in m-c, m-bc and xpcshell harnesses.
10:28bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1380470 General, normal, mdeboer, ASSIGNED , Allow tasks to be skipped or only one task to run in all suites
10:31marcojmaher|afk: when running ts_paint, I see Firefox starting and closing once, then the actual test
10:33marcoah, it opens getInfo.html first, probably to get some information
10:36marcojmaher|afk: is it possible to use SpecialPowers in a talos test?
11:35jmaher|afkmarco: the first launch of firefox is to initialize the profile and ignore the profile creation since it is a fresh profile
11:36jmaher|afkmarco: we have talospowers :)
11:37marcojmaher|afk: okok, ty
11:37marcojmaher|afk: I'm looking into TalosPowers
11:54marcojmaher|afk: is there a way to get the path to the objdir in talos? buildconfig can't be imported ("ImportError: No module named buildconfig")
12:05jmaher|afkmarco: locally, or in automation?
12:08marcojmaher|afk: both
12:09jmaher|afkin automation we don't have an objdir, we download the packaged binary and packaged test bits
12:09jmaher|afklocally via mach we have access to more context
12:10marcojmaher|afk: I need to get the path where the gcda files are stored
12:10marcoto remove all of them after the initial profile creation run
12:10jmaher|afkis that the same path as where firefox is located?
12:16marcojmaher|afk: they are at the same path of the object (.o) files
12:16marcobut not all in dist/bin/ as the firefox binary
12:18jmaher|afkmarco: hmm, I don't know for sure how to get all of that- wouldn't this be the same in our other automation though (for mochitest, xpcshell, etc.)
12:21marcojmaher|afk: here's what the gcda uploader code is doing for finding the dir: https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/testing/codecoverage.py
12:23marcoI'm trying to figure out how it is working
12:23marcogcov_dir is a temporary directory
12:23jmaher|afkmarco: give me a few minutes, I can probably figure this out
14:04gmierzekyle: jmaher: marco: Here's a preview page for the diff tool: https://gmierz.github.io/moz-coco-preview/
14:06ekylegmierz: cool!
14:07ekylethat brings up the question: there are a lot of changesets: how does Relman choose one? A list of changesets my be too long
14:08ekylelogically blocking them into pushes might help
14:08gmierzekyle: There is no list of changesets, I should cchange the wording there
14:08ekylegmierz: Oh, do not take my words as issues, just wondering out loud
14:09marcoit would be good to have a list of recently landed changesets
14:09ekylemaybe a search bar: allow searching by bug, bug description or changesetid
14:10ekylemarco: yes, the pushes, the changesets in them, and the push date
14:10marcoand searching by bug
14:10marcogmierz: have you considered putting this tool on a separate repository?
14:10marcococo is really unpolished and only useful for us as a debugging tool
14:10marcoI'm pretty sure its interface is going to confuse "normal" users
14:13gmierzekyle: marco: I'll start by using this list with pushid, dates, and changeset for now: https://hg.mozilla.org/mozilla-central/json-pushes?startdate=1+week+ago&tochange=9dd2156225d334fc9c164017b7c5068273bfb7ca we can build a search bar that overrides all the other options later.
14:13marcogmierz: ok!
14:13ekylemarco: yes, these specialized interfaces have often ended up being confusing to normal users; we have codecov.io to model, so hopefully we will not be too confusing.
14:14marcogmierz: 1 week might be too long
14:14marcoekyle: yep, but while we rewrite the UI, it would be better not to show the unpolished one
14:14marcobasically, just keep the left bar hidden :P
14:14marco*left sidebar
14:14ekylemarco: ok, we will keep https://gmierz.github.io/moz-coco-preview/ a secret; but we need it to discuss UI development
14:15gmierzmarco: Ok, I can make that bar hidden by default, I think that would be the only confusing part about it
14:15marcogmierz: indeed, it's the "Coverage Queries" part that is confusing
14:15marcoekyle: yes, I'm talking about when we deploy it and make people test it
14:15gmierzmarco: Ok, sounds good. Otherwise, that page will look the same on any repo.
14:16marcogmierz: yeah by "separate repo" I actually meant "making this tool separate from the rest of coco"
14:20gmierzmarco: Ah! I looked into that, but coco already has everything we need for doing the async queries. It also has a nice component-based way of building which I like. So, I don't want to rewrite all of that. But what I can do is remove the coverage queries entry (so we can no longer access that part of coco) and hide the sidebar by default, that way
14:20gmierzit would leave out the confusing parts and leave us a sidebar that we can use to switch between different tools (complete coverage diff, coverage patch diff, etc.) when/if we add more tools.
14:20marcogmierz: yes, that makes perfect sense
14:20gmierzmarco: Awesome :)
14:21marcogmierz: it would be nice to also support query parameters (e.g. ?changeset=XXX)
14:21marcoso people can share URLs to diff views
14:21gmierzmarco: Oh yea! That would be really nice, I'll look into that.
14:29whimbooRyanVM: hey. do you know the condition when we enable e10s nowadays in beta if it was disabled due to eg some non-multiprocess compatible addons?
14:29whimboojust disabling them all doesn't help
14:29RyanVMhrm, I would have expected that to work
14:29RyanVMabout:support says it's disabled due to incompatible addons?
14:30whimbooit only said disabled
14:30whimboono idea why
14:30whimbooi had to do a reset of the profile to get it enabled
14:30RyanVMhrm, almost makes it sound like the pref is set for disabling then
14:30RyanVMif the e10srollout addon were disabling it, a reason should have been given
14:31whimboohm, i don't have my timemachine backup with me, so I cannot restore the profile :/
14:31whimbooi will keep an eye on it if it happens again with another proifle
14:34whimbooRyanVM: i'm trying to see if the current behavior when we show the tab crash icon is what we always did, or if it is a regressoin
14:34whimboobug 1380991
14:34bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1380991 Tabbed Browser, normal, nobody, NEW , Tab crash indicator is only shown for the currently selected tab but not for others of the same content process
14:35whimboothis is kinda odd
14:35RyanVMi'm pretty sure that was an intentional change, yes
14:35whimboonot sure if I filed that into the right component
14:37whimbooi think I will just ask cpeterson
14:37RyanVMbug 1209689 looks relevant to you
14:37bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1209689 General, normal, mconley, RESOLVED FIXED, Crashed tab indicates all tabs have crashed and every tab loads the crashed tab page
14:44whimboothanks
14:51ewrighthey folks. It looks like something in the last week has made me unable to run the 'firefox-ui-functional' marionette tests on mac. I've tried on 3 different macs and one windows machine, windows runs fine. All 3 macs fail with the error "MainThread Error Failure during harness execution" then some trace, then "IOerror: Content process crashed" I searched
14:51ewrightbugzilla and can't find related bugs. any advice on where to file this?
14:51whimbooewright: yes
14:52whimboosee bug 1379906
14:52bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1379906 Marionette, critical, haftandilian, NEW , Assertion and crash during startup when running Marionette tests
14:52whimbooas workaround for now I use --pref security.sandbox.content.level:2
14:53ewrightgreat, thanks you!
14:54whimbooi hoep that I get to this bug soon
14:55whimbooewright: thanks again for the testcase with no outer window id! that was pretty helpful to know why it fails
14:56ewrightno problem, happy I can be helpful sometimes
14:56whimbooit were already 4 times!
15:16whimboooh, the unix timestamp increased to 15 at the beginning not that long ago
15:55jmahermarco: ok, so let me work on solving your problem here with talos and objdir
15:55marcojmaher: thanks!
15:56jmahermarco: can we look for files in os.environ['GCOV_PREFIX'] ?
15:56jmaherand I guess os.environ['JS_CODE_COVERAGE_OUTPUT_DIR'] as well
15:57marcoare they defined when you run talos locally?
15:58jmaherone sec
16:04jmahermarco: if we run talos locally with coverage then the env variables should be set
16:06marcojmaher: trying
16:07marcojmaher: they are both undefined in my local env
16:07marcojmaher: here's my mozconfig https://pastebin.mozilla.org/9027091
16:09jmahermarco: hmm- let me see how we run it in automation
19:52emorleygbrown: re bug 1380666 - the kanban user is a bot - perhaps ask in #moc?
19:52bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1380666 WebOps: Other, normal, server-ops-webops, NEW , Update sudoers list for brasstacks1.dmz.scl3.mozilla.com
19:53gbrownemorley: ha! can't believe I ni'd a bot! thanks
19:54emorleytoo many bots/different tools!
19:55emorleyon the plus side at least we don't have as many redundant systems as we used to (eg VCSes, about to get rid of intranet.m.o etc)
19:56jmahergbrown: I have ni'd a bot before
20:12* wlach wonders if face has anything to say about this
20:15emorleyhe's busy waiting for a reply to his needinfos haha
21:36RyanVMgbrown: RIP inbox :(
21:37gbrownRyanVM: really? I didn't get any bugmail for all that
21:38RyanVMguess we can tell who was filing oranges before the bug filer existed :P
21:38gbrownRyanVM: anyway, sorry!
21:55dylanpah, that's a paltry amount of bugmail
21:55dylanthe jobqueue only alerted a little
22:37KWiersogbrown: you don't get bugmail when you're the one making the change
22:38gbrownthat explains it!
15 Jul 2017
No messages
   
Last message: 71 days and 21 hours ago