log viewer should use "logname" field of text_log_summary, if present, for logslice

RESOLVED FIXED

Status

Tree Management
Treeherder: Log Viewer
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: camd, Assigned: camd)

Tracking

Details

Attachments

(2 attachments)

(Assignee)

Description

2 years ago
we should support custom names of logs in the log viewer, not just our hard-coded ones.
(Assignee)

Updated

2 years ago
Assignee: nobody → cdawson

Updated

2 years ago
Component: Treeherder → Treeherder: Log Viewer
(Assignee)

Comment 1

2 years ago
As we move away from buildbot, having the logs named after builbot starts making less sense.  This frees us from that.
(Assignee)

Comment 2

2 years ago
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.
(Assignee)

Comment 3

2 years ago
Created attachment 8631896 [details] [review]
PR
Attachment #8631896 - Flags: review?(mdoglio)
(Assignee)

Updated

2 years ago
Summary: log viewer should use "name" field of text_log_summary, if present, for logslice → log viewer should use "logname" field of text_log_summary, if present, for logslice
Attachment #8631896 - Flags: review?(mdoglio) → review+

Comment 4

2 years ago
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.
(Assignee)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
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\": \"..."}"
                },
]
(Assignee)

Updated

2 years ago
Flags: needinfo?(cdawson)
(Assignee)

Comment 6

2 years ago
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.
(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.
Flags: needinfo?(cdawson)
You need to log in before you can comment on or make changes to this bug.