mozilla :: #treeherder

15 Mar 2017
02:20herokubotdeployed daee045 to treeherder-prod
10:34herokubotdeployed 9a4d2de to treeherder-prototype
10:35herokubotdeployed 9a4d2de to treeherder-stage
13:52herokubotdeployed 170b363 to treeherder-stage
13:53herokubotdeployed 170b363 to treeherder-prototype
13:54emorleyI'll do a master-> prod push now unless anyone has objections?
13:56jgrahamNo objections
14:53herokubotdeployed 170b363 to treeherder-prod
15:21herokubotdeployed 23ed987 to treeherder-prototype
15:21herokubotdeployed 23ed987 to treeherder-stage
16:20emorleyI hadn't realised that revert PR hadn't yet landed, so I'm going to cherry-pick again to prod (since earlier's master->prod push blew it away)
16:31herokubotdeployed fbe0b94 to treeherder-prototype
16:31herokubotdeployed fbe0b94 to treeherder-stage
16:34herokubotdeployed b132e9f to treeherder-prod
16:49camdemorley: thanks for landing that. :)
16:52jgrahamemorley: Did my email not make it to the treeherder mailing list?
16:53emorleyjgraham: I received it
16:53emorleyand I can see it on https://groups.google.com/forum/#!forum/mozilla.tools.treeherder
16:53emorley(I'm signed up via mailman)
16:56jgrahamemorley: OK, I guess I just don't get my own mail or something
16:56jgrahamI should have checked google groups
17:07camdemorley: I was thinking we should perhaps add a new bugzilla component of "Treeherder: Test Centric UI" or something to that effect. What's your opinion?
17:08emorleyI'm in favour of adding more components
17:08emorleyI wonder if it's a bit soon? (Just so we get the name right)
17:08emorleyAlso we have things like autoclassify without a component
17:08emorleythe main Treeherder component is a bit of a dumping ground admitedly
17:09emorleylet's have a think :-)
17:12davehuntAre there specific values expected for buildMachine platform, and os? The schema suggests spaces are not permitted.
17:12davehuntI was using platform: Mac OS X, os: Mac OS X 10.12.3
17:13davehuntbut that's not valid :)
17:14davehuntfrom watching pulse inspector I see jobs using 'linux32' for example
17:15davehuntI'm guessing Treeherder does something smart with that, as the os and architecture are '-'
17:17wlachdavehunt: there is a pulse schema you can validate against here https://github.com/mozilla/treeherder/blob/master/schemas/pulse-job.yml it defines the restrictions for names
17:17davehuntwlach: yep, that's what I'm running :)
17:18davehuntI think this is what I'm looking for: https://github.com/mozilla/treeherder/blob/master/ui/js/values.js#L3
17:18wlachdavehunt: so if you look at the definition for machine it defines exactly what regular expression it will accept
17:18wlachdavehunt: no, that's a red herring :) it's all in the schema
17:19davehuntwlach: not really, to get it to display "OS X 10.10" I need to pass "osx-10-10" as the platform
17:19wlachdavehunt: oh, I see what you mean. yes
17:19davehuntI maybe asked the wrong question, but that's my answer :)
17:19wlachas a bonus that will save us a few database rows :)
17:19davehuntI am not quite sure how to wrangle what I get from Java into that though
17:24davehuntwlach: do you think it would be acceptable to pass what I get from Java, say lowercase and replace spaces with dashes, and then just add more entries to that map..?
17:25wlachdavehunt: could you not do some kind of etl inside your java code to translate whatever you get there to the value in value.js?
17:25davehuntso I might have mac-os-x-10-12-3 (though in reality our tests are not running on Macs, that's just what I'm getting locally)
17:26wlachdavehunt: seems like you might as well mirror what's in value.js as long as you're transforming things...
17:26davehuntI wouldn't know the potential values, though our Jenkins won't change so I could hardcode some assumptions
17:28davehunta simple lowercase and replace is easy, however matching the map keys from values.js would take quite a bit more work
17:30davehuntwlach: if platform includes the os, it's not clear what should the os key should contain
17:31wlachwhy not? can't you derive the os name from the platform+osname?
17:31davehuntbut the platform == the os name?
17:31davehuntor is os name the os without the version?
17:32davehuntfwiw the schema could benefit from a bit more documentation :)
17:32wlachhere's what we have in treeherder: https://treeherder.mozilla.org/api/machineplatform/
17:32herokubotdeployed fd4c5b5 to treeherder-prototype
17:32herokubotdeployed fd4c5b5 to treeherder-stage
17:33wlachdavehunt: it looks like os name is typically something short like "mac" or "win32'
17:33davehuntwlach: okay, found a few examples that help, though it looks like there's little point having os and arch as required if the values are often '-'
17:34wlachdavehunt: most of the time when the values are '-' that's a bad/incomplete submitter
17:34davehuntthat's what TaskCluster does, though
17:35davehunthmm.. there are also values in that output that do not conform to the schema.. such as "platform": "Mac OS X 10.11.4 x86_64"
17:35wlachI think the pulse job schema checking is more rigidly enforced than treeherder's
17:35davehuntk
17:35wlachs/more rigidly enforced/more rigid/
17:36wlachI agree the present situation is pretty poorly documented
17:36davehuntI can work with this, and happy to contribute docs as I learn
17:36wlachthat's great, thanks for your patience :)
17:37wlachi think the best place to put docs would be in the schema itself, if you can
17:38davehuntagreed
17:38wlachdavehunt: jonasfj's action task schema is a good example of "how to do it" (IMO) http://searchfox.org/mozilla-central/source/taskcluster/docs/actions-schema.yml
17:39wlachthough actually now that I look at it the pulse job schema has some decent descriptions too
17:40wlachjust not in the particular area we're talking about
17:40davehuntyeah, some parts I've been able to follow the descriptions
17:50jonasfjJSON schema + descriptions makes for some super solid reference docs...
17:50jonasfjI wish there was a way to get docson on github pages and/or readthedocs...
17:51jonasfjdocson is the widget that displays schemas as UI on docs.taskcluster.net
18:31camdEli: OK, I pushed those changes to use ``await`` now. Good to proceed with the review. Thanks.
18:32Elicamd: thanks!
19:00herokubotdeployed 4155feb to treeherder-prototype
19:00herokubotdeployed 4155feb to treeherder-stage
21:07KWiersodo we have anything to take a test failure line and parse out the path to a failing test in the srcdir?
21:08camdKWierso: that may take a few api calls, but I think you could get there, yeah
21:08camdnothing built-in that I know of, however
21:11KWiersoa bunch of test (suites?) print them out with the srcdir path, but others end up with something like > file:///C:/slave/test/build/tests/reftest/tests/layout/reftests/svg/filters/svg-filter-chains/long-chain.svg | application timed out after 330 seconds with no output
21:11KWiersowhere the srcdir path starts with "layout/"
21:12KWiersowant to be able to hit up http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/mozbuildinfo.html 's api to get recommended components for the bug filer, but I need to get to the srcdir paths to be able to use that
21:12KWiersomaybe it's just reftests that fail like that? guess I could skip them for now and just improve things for tests that behave better...
21:18camdKWierso: can you point me to an example job in treeherder?
21:18KWiersocamd:
21:18KWiersohttps://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=749de78b48317d8e6f0206cd81b1604c38f0d70b&bugfiler&noautoclassify&filter-tier=1&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=running&filter-resultStatus=pending&filter-resultStatus=runnable&selectedJob=84097068&filter-classified
21:18KWiersoState=unclassified
21:18KWiersoyou'll need to append that last bit manually, I guess
21:30KWiersowonder if there's anything in structured logging that would help...
21:34jgrahamAt some point ahal was adding the test path to structured logs
21:34jgrahamdunno how far he got
21:34camdKWierso|brb: hrm, I see what you mean. Yeah, I think the first entry of the structured logs might have that.
21:35camdYou'd have to get the job_detail for the job, then get the xxx_errorsummary.log for the test in question
21:35camdthen take the first entry of the errorsummary.log
21:36camdKWierso|brb: this is a mochitest one, but like this: https://public-artifacts.taskcluster.net/B9RIy3v3TFqxA6XlsUpu9A/0/public/test_info//mochitest-gl_errorsummary.log
21:46emorleycamd: it will already be ingested, so no need to fetch that file :-)
21:47camdemorley: but it won't have the list of all tests, right? Just the failure lines
21:47camdof course I guess perhaps that's what KWierso|brb is looking for... let me take a look at the file again...
21:47emorleythe new autoclassify panel has the test names for failing tests
21:48camdoh cool, I haven't actually looked at that yet... :)
21:50emorleyor at least I thought it does, I could be wrong!
21:52KWiersoit bolds the filename when it thinks it can find it
21:52KWiersodoesn't do anything differently for the file::// paths, though
21:55emorleyI mean, I thought one of the new tables held the test names from the structured error summary
22:09emorleyeg gthe `test` attribute in one of the items here https://treeherder.allizom.org/api/project/mozilla-inbound/jobs/78453595/failure_lines/
22:11emorleythough I'm sure James will have better advice as to what to use :-)
22:13herokubotdeployed 2b0ef8a to treeherder-prototype
22:13herokubotdeployed 2b0ef8a to treeherder-stage
22:52herokubotdeployed 88cf592 to treeherder-stage
16 Mar 2017
No messages
   
Last message: 10 days and 12 hours ago