mozilla :: #treeherder

20 Apr 2017
01:18herokubotdeployed 2fade37 to treeherder-prototype
01:18herokubotdeployed 2fade37 to treeherder-stage
09:09herokubotdeployed 3bbe1af to treeherder-prototype
09:09herokubotdeployed 3bbe1af to treeherder-stage
11:57herokubotdeployed 6ea89d0 to treeherder-stage
11:57herokubotdeployed 6ea89d0 to treeherder-prototype
15:46emorleycamd, jgraham: I'm experimenting with using the GitHub request review feature instead of r? on Bugzilla to reduce number of steps for both assignee and reviewer. However not sure how buried the notifications get compared to the Bugzilla ones that don't thread with everything else. Also it will mean they don't appear in the Bugzilla queues or the daily
15:46emorleyreminder emails. Happy to also use Bugzilla review flags if preferred.
15:47jgrahamemorley: Yeah it's difficult; the GH review requests are way lower friction, but they are also very prone to getting lost
15:47jgrahamWould be nice if there was some tooling here
15:49emorleyGitHub has https://github.com/pulls/review-requested , not not surfaced in the main UI and no reminders / reports of review times etc
15:49emorleys/not not/but not/
15:49jgrahamIndeed
15:49emorleyI guess we could write something to poll the GitHub API and eg email people (or the treeherder-internal list)
15:51jgrahamThat would be interesting
16:27camdemorley: Yeah, that was my only concern here, too. I like how "in your face" the bugzilla list is. I wish there was an option that the github tab would show a count of waiting reviews. But an email is a nice second option.
18:02herokubotdeployed 2edd775 to treeherder-prototype
18:02herokubotdeployed 2edd775 to treeherder-stage
20:41erahmHi treeherder folks, I seem to be getting bad results from TreeherderClient.get_job_log_url. I'm asking for the urls of 99 jobs, but only getting 21 back
20:41erahmhttps://irccloud.mozilla.com/pastebin/ZiOiTAA4/
20:44erahmI guess it's possible the job id's are wrong, but they came from client.get_jobs
20:44KWiersoerahm: wonder if the missing ones aren't parsed yet or something?
20:45erahmKWierso: don't think so
20:46camderahm: Are you able to try the same url through curl?
20:46camdCould track down if there's a bug in the client, or in treeherder.
20:48erahmcamd: I don't know what the URL is, I just use the python client
20:49camderahm: I can try doing a query directly on the DB and see what I get. Just a minute
20:49erahmKWierso, camd: so basically I'm trying to get the job logs for win7-32-vm on https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=bf7bd2981c424fb72e1199bb5a67ee5822615099
20:51camderahm: I only see 21 in the db for those job ids.
20:51camdSo perhaps KWierso is right on that.
20:52erahmcamd: I can visually count like 40
20:52KWiersocamd: seems unlikely given https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=bf7bd2981c424fb72e1199bb5a67ee5822615099&group_state=expanded&filter-platform=windows%207%20vm&filter-tier=1&filter-tier=2&filter-tier=3&exclusion_profile=false
20:53KWiersopin-all counts 82
20:53wlachthe job log url endpoint doesn't seem to care whether a log is parsed or not https://github.com/mozilla/treeherder/blob/master/treeherder/webapp/api/job_log_url.py#L44
20:53erahmSo I think I'm getting bunk ids
20:53camderahm: that's more likely, yeah
20:53wlacherahm: yeah how you're getting ids would be the better question maybe
20:53camdAgreed. :)
20:53erahmwlach: one sec I'll dig that up
20:53wlachour jobs endpoint is kind of horrible (I know because I wrote most of its current incarnation)
20:59erahmwlach: jobs = client.get_jobs('mozilla-inbound',result_set_id=194399, count=5000, platform='windows7-32-vm', option_collection_hash='32faaecac742100f7753f0c1d0aa0add01b4046b')
21:02wlacherahm: resolving that to https://treeherder.mozilla.org/api/project/mozilla-inbound/jobs/?result_set_id=194399&platform=windows7-32-vm&count=2000&option_collection_hash=32faaecac742100f7753f0c1d0aa0add01b4046b
21:03wlacherahm: I see a lot of jobs with start_timestamp = 0, which I guess indicates that they haven't been run yet, and thus maybe don't have logs?
21:04KWiersowlach: that push is complete, though: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=bf7bd2981c424fb72e1199bb5a67ee5822615099&group_state=expanded&filter-platform=windows%207%20vm&selectedJob=92783452
21:04wlacherahm: yeah actually maybe add state=completed to your jobs query
21:04erahmwlach: this is from a day or two ago, visually looking in treehereder we see there's more the 21 jobs completed
21:04wlachhmm
21:05erahmwlach: eeeeeeesh that gives me 11
21:05erahmI wonder if that's even the right result_set_id...
21:05KWiersoerahm: from wlach's link, a lot of jobs are still in "pending" state
21:06erahmbut that's clearly wrong :(
21:06wlacherahm: KWierso: oh yeah I think the result_set_id is wrong
21:07wlachKWierso's link resolves to rs 194513, whereas you're looking up 194399
21:09* erahm sighs
21:10KWiersowheee :)
21:10erahmwlach: sorry, yeah bisection got confused and used the wrong changeset
21:10erahmwlach: it is odd we have so many pending though
21:36wlacherahm: mmm, yeah, I dunno... I guess we could look up the revision that refers to
21:37erahmwlach: I think it was this: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=9142443a4ca2&group_state=expanded&filter-platform=windows%207%20vm&filter-tier=1&filter-tier=2&filter-tier=3&exclusion_profile=false
21:37erahmso the numbers seem right, I just don't get why there are so many pending
21:40wlachyeah esp. since they don't seem visible in that view
22:07herokubotdeployed 589817d to treeherder-stage
22:07herokubotdeployed 589817d to treeherder-prototype
21 Apr 2017
No messages
   
Last message: 8 days and 3 hours ago