Autophone currently submits a "privatebuild" artifact to treeherder as part of each run, however the information therein isn't exposed anywhere in the UI. https://github.com/mozilla/autophone/blob/cf913b782187993c3afb432e377e8bff1a61f80f/autophonetreeherder.py#L198 :bc, how are you using this information? I want to streamline treeherder by removing the artifact model, it turns out that Treeherder doesn't work well as a general data store (it's a big distraction from the error parsing and analytics that is its primary function). Some alternatives to an artifact might be: * Store these fields as job details (by submitting a job info artifact). This will also expose them in the treeherder UI * Store these fields in the log that autophone submits * Store the JSON blob in Amazon S3 and link to it via a jobdetail.

I submit it when I create the job as pending and use it later when dealing with pulse job action messages. I don't need to expose this in the UI. If I understand the situation correctly, Job Info/job details can only be written once which I currently do when the Job is completed. If I can send Job Info/job details when I send Pending, Running and Completed jobs and if it is easy to look up I can store the information as a json file in S3. I'll look again at the information that is available to me and see if this is still necessary.

(In reply to Bob Clary [:bc:] from comment #1) > I submit it when I create the job as pending and use it later when dealing > with pulse job action messages. I don't need to expose this in the UI. > > If I understand the situation correctly, Job Info/job details can only be > written once which I currently do when the Job is completed. If I can send > Job Info/job details when I send Pending, Running and Completed jobs and if > it is easy to look up I can store the information as a json file in S3. > > I'll look again at the information that is available to me and see if this > is still necessary. This wasn't the case before, but you can now submit a "job info" artifact multiple times and it will ingest any new job details when you do so.

I'm in a bit of a hurry to get this implemented as it's blocking treeherder transitioning to a more sane database structure (which will unlock a lot of other interesting things). Here's a proof of concept where we store this information as job details: bc, what do you think?

I made some comments in the pr and ran a test against staging with noted changes. It appears there is an error on th's side: https://rpm.newrelic.com/accounts/677903/applications/5585473/filterable_errors#/show/4c9980ba-815d-11e6-a90b-b82a72d22a14_0_5010/stack_trace?top_facet=transactionUiName&primary_facet=error.class&barchart=barchart&_k=yqm0wl I'm still on th client 3.0.0. Do I need to upgrade to 3.1.0 as well?

(In reply to Bob Clary [:bc:] from comment #4) > I made some comments in the pr and ran a test against staging with noted > changes. It appears there is an error on th's side: > > https://rpm.newrelic.com/accounts/677903/applications/5585473/ > filterable_errors#/show/4c9980ba-815d-11e6-a90b-b82a72d22a14_0_5010/ > stack_trace?top_facet=transactionUiName&primary_facet=error. > class&barchart=barchart&_k=yqm0wl > > I'm still on th client 3.0.0. Do I need to upgrade to 3.1.0 as well? No, that's a bug in treeherder. :) I'll fix it.

(In reply to William Lachance (:wlach) from comment #5) > (In reply to Bob Clary [:bc:] from comment #4) > > I made some comments in the pr and ran a test against staging with noted > > changes. It appears there is an error on th's side: > > > > https://rpm.newrelic.com/accounts/677903/applications/5585473/ > > filterable_errors#/show/4c9980ba-815d-11e6-a90b-b82a72d22a14_0_5010/ > > stack_trace?top_facet=transactionUiName&primary_facet=error. > > class&barchart=barchart&_k=yqm0wl > > > > I'm still on th client 3.0.0. Do I need to upgrade to 3.1.0 as well? > > No, that's a bug in treeherder. :) I'll fix it. Actually on second thought, maybe we shouldn't fix that (see bug 1305070 for diagnosis + my reasoning). I'll update the autophone patch instead.

Comment on attachment 8793951 [details] Proposed PR I addressed your issues, I also think I fixed the error (we were trying to create a jobdetail with integer content, which treeherder doesn't support).

Retriggering a job: HTTP Error 404: NOT FOUND Unable to open https://treeherder.allizom.org/jobdetail/?repository=autoland&job_id=3968647 The job detail is a 404. Is this the correct url and is this available on staging?

(In reply to Bob Clary [:bc:] from comment #8) > Created attachment 8794530 [details] > HTTP Error 404: NOT FOUND > > Retriggering a job: > > HTTP Error 404: NOT FOUND Unable to open > https://treeherder.allizom.org/jobdetail/?repository=autoland&job_id=3968647 > > The job detail is a 404. Is this the correct url and is this available on > staging? Sorry, my bad, I missed the `/api/` part of the URL. Perils of writing code without testing it. :( This works: https://treeherder.allizom.org/api/jobdetail/?repository=autoland&job_id=3968647 I've updated the PR.

Although Build is available the build_url is truncated: {u'url': None, u'job_guid': u'e7240164-7405-4936-97e9-8b9dfa484681', u'job_id': 3972334, u'value': u'https://queue.taskcluster.net/v1/task/KQr4xADPT_yO16U3QYQwtQ/runs/0/artifacts/public/build/fennec-52.0a1.en-US.android-arm.ap', u'title': u'build_url'}, I don't have time to spend on this so close to the end of the quarter. I'll use this as a guide for how to handle the job details but I'll start from scratch later.

(In reply to Bob Clary [:bc:] from comment #10) > Created attachment 8794537 [details] > https://treeherder.allizom.org/api/jobdetail/ > ?repository=autoland&job_id=3972334 > > Although Build is available the build_url is truncated: > > {u'url': None, u'job_guid': u'e7240164-7405-4936-97e9-8b9dfa484681', > u'job_id': 3972334, u'value': > u'https://queue.taskcluster.net/v1/task/KQr4xADPT_yO16U3QYQwtQ/runs/0/ > artifacts/public/build/fennec-52.0a1.en-US.android-arm.ap', u'title': > u'build_url'}, > > I don't have time to spend on this so close to the end of the quarter. I'll > use this as a guide for how to handle the job details but I'll start from > scratch later. Ok, I think we can get around this problem by submitting the build url as an actual job details url, which doesn't have such a short length restriction. I updated the PR to show how that might be done, but of course I haven't tested it, so there may well be further problems. I'm totally fine if you want to rewrite the patch. I just wanted to help move things along. :) The motivation for this work is to get all of the treeherder data into a single database, which should facilitate using tools like redash to generate better analytics and adhoc dashboards of data inside treeherder -- which I'd like to do for investigating intermittent trends, resource consumption, etc. This is one of the last dependencies for that, so I'd like to get it done sooner than later, but waiting until the first or second week in Q4 would be fine (there are other things I can work on in parallel).

:bc, ping on this bug. Do you think you'll have time to look at this soon? This is blocking the deprecation of the artifacts API, which is blocking bug 1178641 (which I'm trying to get done by the end of this month). I actually think we're really close here. If my last PR doesn't work, the modifications needed should be minimal.

wlach: Yes, I'll get to it later today.

Comment on attachment 8793951 [details] Proposed PR Looks fine. Please add the warning and you should be good to go.

(In reply to Bob Clary [:bc:] from comment #14) > Comment on attachment 8793951 [details] > Proposed PR > > Looks fine. Please add the warning and you should be good to go. I added a warning. I'll leave it to you to merge in (feel free to tweak it as wanted before you do)

Thanks. https://github.com/mozilla/autophone/commit/010b9460e3fb7fcb6642390c6c8981111fb562d6 deployed 2016-10-25 08:00 PT