Bug 1603249 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

After chatting with Tom.Prince the other day, I've come into new information about what we store in the `JobDetail` table. In a nutshell, in addition to storing uploaded artifacts in the table we're also parsing log lines with the name "TinderboxPrint" and storing them in the table. Much of that content seems to be of questionable value and could be found by someone looking at the logs. I also found an old [bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1342296#c0) filed by Ed with a useful, if somewhat outdated, analysis.

So before I can proceed with the removal of the jobdetails endpoint completely we need to figure out if we should keep supporting that log parsing/storing of data. I'll reopen bug 132296 as a meta (it was closed as invalid) and add an update since some of the information is no longer applicable.

I think the approach to take is to continue with the idea of deprecating the use of /jobdetail/ endpoint for uploaded artifact retrieval both in our UI and for mozscreenshots. 

For the job details panel in TH, we'll need to still retrieve the job details that are *not* uploaded artifacts (from TinderboxPrint and anything else) until we decide what, if anything, we should store in JobDetail. But this will at least cut down on a large chunk of the writes to the table in the meantime.
After chatting with Tom.Prince the other day, I've come into new information about what we store in the `JobDetail` table. In a nutshell, in addition to storing uploaded artifacts in the table we're also parsing log lines with the name "TinderboxPrint" and storing them in the table. Much of that content seems to be of questionable value and could be found by someone looking at the logs. I also found an old [bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1342296#c0) filed by Ed with a useful, if somewhat outdated, analysis.

So before I can proceed with the removal of the jobdetails endpoint completely we need to figure out if we should keep supporting that log parsing/storing of data. I'll reopen bug 1342296 as a meta (it was closed as invalid) and add an update since some of the information is no longer applicable.

I think the approach to take is to continue with the idea of deprecating the use of /jobdetail/ endpoint for uploaded artifact retrieval both in our UI and for mozscreenshots. 

For the job details panel in TH, we'll need to still retrieve the job details that are *not* uploaded artifacts (from TinderboxPrint and anything else) until we decide what, if anything, we should store in JobDetail. But this will at least cut down on a large chunk of the writes to the table in the meantime.

Back to Bug 1603249 Comment 9