1343239 - Cleanup the /jobdetails/ API endpoint and usage by the UI

Status: RESOLVED INVALID

(Tree Management :: Treeherder: API, enhancement, P1)

Description

[Ed Morley [:emorley]]

Issues:

1) The UI makes calls like:
http://localhost:8000/api/jobdetail/?job_guid=3edb9a197bb1a1473bdc0d11494a986b8ece6748
...rather than using job_id which is on the table itself

2) The endpoint supports both `job_guid` and `job__guid` as parameter names, which is fine for transition, but can be cleaned up now

3) That said, I think we should just unsupport both passing job_guid and returning the guid in the response, which would avoid needing to include `job` in select_related too.

4) The queryset unnecessarily includes `repository` in select_related when that table is only used for filtering and not referenced in the response.

5) That said, I can't see a valid use case for filtering by `repository` (seeing as one of job_guid/job_id is mandatory anyway), so we should just remove support for it.


Just to give an example:

http://localhost:8000/api/jobdetail/?job_guid=3edb9a197bb1a1473bdc0d11494a986b8ece6748

returned:

{
    "next": null,
    "previous": null,
    "results": [
        {
            "job_id": 5776,
            "job_guid": "3edb9a197bb1a1473bdc0d11494a986b8ece6748",
            "title": "artifact uploaded",
            "value": "resource-usage.json",
            "url": "http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/49081b45cae996004ef1f6a65e39c2ea6adab3bf9ce0968113567f057532365d86e3277791c193b36e2244b15ee7cf63d000f4d9bd3786d9f352aec9f476e488"
        },
...

Via this:

SELECT job_detail.id,
job_detail.job_id,
job_detail.title,
job_detail.value,
job_detail.url,
job.id,
job.repository_id,
job.guid,
job.project_specific_id,
job.coalesced_to_guid,
job.signature_id,
job.build_platform_id,
job.machine_platform_id,
job.machine_id,
job.option_collection_hash,
job.job_type_id,
job.product_id,
job.failure_classification_id,
job.who,
job.reason,
job.result,
job.state,
job.submit_time,
job.start_time,
job.end_time,
job.last_modified,
job.running_eta,
job.tier,
job.push_id,
repository.id,
repository.repository_group_id,
repository.name,
repository.dvcs_type,
repository.url,
repository.branch,
repository.codebase,
repository.description,
repository.active_status,
repository.performance_alerts_enabled
FROM job_detail
INNER JOIN job ON (job_detail.job_id = job.id)
INNER JOIN repository ON (job.repository_id = repository.id)
WHERE job.guid = '3edb9a197bb1a1473bdc0d11494a986b8ece6748'
ORDER BY job_detail.id DESC
LIMIT 2001;

When it could have just used:

SELECT job_detail.job_id,
job_detail.title,
job_detail.value,
job_detail.url,
FROM job_detail
WHERE job_detail.job_id = 5776
ORDER BY job_detail.id DESC
LIMIT 2001;

Comment 1

[William Lachance (:wlach)]

A lot of this weirdness is due to datasource legacy. No arguments from me that we should clean it up.

Comment 2

[Ed Morley [:emorley]]

Yeah agree, not saying it's surprising it's like it is - I just wanted to file with enough details before I forgot the potential cleanup I'd spotted :-)

Comment 3

[Ed Morley [:emorley]]

Fixing issues 3/4 from comment 0 would have helped avoid bug 1386331.

Comment 4

[Cameron Dawson [:camd]]

#1 has been addressed already in one of my PRs. But these other improvements sound great. It's an important query and improving performance here would really help.

Comment 6

[Armen [:armenzg]]

Attachment: [screenshot] Improvements suggested by New Relic

Comment 7

[Sarah Clements [:sclements]]

Since it was removed in bug 1342296.