Last Comment Bug 1182299 - log viewer should use "logname" field of text_log_summary, if present, for logslice
: log viewer should use "logname" field of text_log_summary, if present, for lo...
Status: RESOLVED FIXED
:
Product: Tree Management
Classification: Other
Component: Treeherder: Log Viewer (show other bugs)
: ---
: All All
-- normal
: ---
Assigned To: Cameron Dawson [:camd]
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-09 14:36 PDT by Cameron Dawson [:camd]
Modified: 2015-07-23 07:45 PDT (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
PR (46 bytes, text/x-github-pull-request)
2015-07-09 17:15 PDT, Cameron Dawson [:camd]
mdoglio: review+
Details | Review | Splinter Review
job collection using log_name "somesillything" (5.54 KB, text/plain)
2015-07-22 13:48 PDT, Maja Frydrychowicz (:maja_zf)
no flags Details

Description User image Cameron Dawson [:camd] 2015-07-09 14:36:09 PDT
we should support custom names of logs in the log viewer, not just our hard-coded ones.
Comment 1 User image Cameron Dawson [:camd] 2015-07-09 16:52:01 PDT
As we move away from buildbot, having the logs named after builbot starts making less sense.  This frees us from that.
Comment 2 User image Cameron Dawson [:camd] 2015-07-09 17:08:37 PDT
Found this while trying to debug an issue Maja was having getting her logs to show.  These changes would have supported her workflow, and helped me track down what was going on faster.
Comment 3 User image Cameron Dawson [:camd] 2015-07-09 17:15:44 PDT
Created attachment 8631896 [details] [review]
PR
Comment 4 User image Treeherder Bugbot 2015-07-13 09:18:52 PDT
Commit pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/51cc8f6a27d8c29f15d34b2390c3e8ae5205cc5e
Bug 1182299 - Support custom log name param in logslice

This adds the ability to specify a custom log name and have the log
viewer use the ``logname`` param of the ``text_log_summary`` to get the
right log.

This also improves the error message returned by the /logslice/ API if a
log name is used that is not found.
Comment 5 User image Maja Frydrychowicz (:maja_zf) 2015-07-22 13:48:39 PDT
Created attachment 8637446 [details]
job collection using log_name "somesillything"

When submitting log_references and text_log_summary in a single post request, using a custom name yields: 

* Request: GET /api/project/mozilla-central/logslice/?end_line=2&job_id=278&start_line=0

* Response: 404 "Expected log names of ['buildbot_text', 'builds-4h'] not found in [u'log_info.log'] for job_id 278".

Note that the there's no "name" query param in the request generated by the UI. (Manually requesting GET /api/project/mozilla-central/logslice/?end_line=2&job_id=278&start_line=0&name=somethingsilly works fine.)

The log steps appear correctly in log viewer if I just submit 'buildbot_text' in my job_collection.

Highlights (full detail available in attachment):
"log_references": [
                {
                    "url": "...",
                    "parse_status": "parsed",
                    "name": "somesillything"
                }
            ],

"artifacts": [
                {
                    "job_guid": "515dfaea-7e85-4f3d-8264-ece1cbab7615",
                    "type": "json",
                    "name": "text_log_summary",
                    "blob": "{\"step_data\": {\"steps\": [...], \"logname\": \"somesillything\", \"errors_truncated\": false}, \"logurl\": \"..."}"
                },
]
Comment 6 User image Cameron Dawson [:camd] 2015-07-22 16:04:49 PDT
Interesting.  I'm going to have to spend some time debugging this.  In simplistic testing, it looked like it would use the param, if it was there.  But I'll have to do an end-to-end by making sure I have a ``text_log_summary`` artifact that has a "logname" param.  

Oh, but looking at your data above, it looks like the "logname" parameter is inside the "steps" param.  It should be a peer to "step_data"; at the top-level of the blob object.  Could that be it?

Like I say, I'll test more when I get back.
Comment 7 User image Maja Frydrychowicz (:maja_zf) 2015-07-23 07:45:36 PDT
(In reply to Cameron Dawson [:camd] from comment #6) 
> Oh, but looking at your data above, it looks like the "logname" parameter is
> inside the "steps" param.  It should be a peer to "step_data"; at the
> top-level of the blob object.  Could that be it?

Yes, that's it! :) Tested again. All is well.

Note You need to log in before you can comment on or make changes to this bug.