Adding those two columns with an index would allow us to call the endpoint with task_id and optionally with run (defaulting with 0 when not specified).
We might be able to get ready of job_guid at that point. We might need to backfill.

Eventually we could allow the UI to use ?selectedTask=<task_id.

Supporting selectedTask would definitely be nice for my purposes, as I wouldn't need to hit the Treeherder API to translate between taskId and jobId.

I'm not sure what you're asking for and if it's for the api/jobs endpoint or the project bound jobs endpoint api/project/<projectName>/jobs/

The api/jobs endpoint returns the task_id and the retry_id (runId) and there's a JobModel class for use in the Treeherder UI. The project bound jobs endpoint for a specific job api/project/<projectName>/jobs/<jobId> also returns those fields. Are you asking for query parameter/field filtering on task_id and retry_id?

For my purposes, I'd need a way to point to a Treeherder job and select a task without having to hit the Treeherder API (https://github.com/mozilla/code-review/blob/81eb5a18767ab3ebbdb2d8547377474495f6b2ab/tools/code_review_tools/treeherder.py#L20-L27).
If there was a way to specify a URL as e.g. https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=553fdf483aafcbf66fe72f7d2b9eb8b9a94c47ee&selectedTask=OkuQUPHuQe-iOy0JBROcEA instead of https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=553fdf483aafcbf66fe72f7d2b9eb8b9a94c47ee&selectedJob=295107279, I wouldn't have to hit the jobdetail API.

I suggest not querying the /jobdetail/ endpoint for anything since I'm working on bug 1603249 to stop storing uploaded artifacts in that table, so it'd affect what's returned in that endpoint. Just querying the jobs endpoint already supplies the needed info for example: https://treeherder.mozilla.org/api/jobs/?job_guid=1a695e35-1065-4120-9d49-1a7c00f8467c/0

Just requires some processing to create key/value pairs.

{"results": [
      [
        2,
        293839762,
        "Xpcshell tests",
        "X",
        "test-linux32-shippable/opt-xpcshell-1",
        "X1",
        "2020-03-19T22:04:04.729591",
        "linux32-shippable",
        666619,
        "testfailed",
        "f25cf1d30a9ae3840d2836aa52c42cc9c1efc4d9",
        "completed",
        2,
        "GmleNRBlQSCdSRp8APhGfA",
        0,
        5,
        "opt"
      ]
    ],
    "job_property_names": [
      "failure_classification_id",
      "id",
      "job_group_name",
      "job_group_symbol",
      "job_type_name",
      "job_type_symbol",
      "last_modified",
      "platform",
      "push_id",
      "result",
      "signature",
      "state",
      "tier",
      "task_id",
      "retry_id",
      "duration",
      "platform_option"
    ]

But I think it'd be doable to support the selectedTask param in the UI because its querying the api/jobs endpoint. I'll try to look into that in the next few weeks.

On second thought, :camd is more familiar with the jobs view UI code. Cam, is adding support for a selectedTask param something you'd be able to work on?

Here is the spot where we select a job based on the URL param:
https://github.com/mozilla/treeherder/blob/36aa9d6d0d469f62042f685742d35ebcd6bcb58f/ui/job-view/redux/stores/selectedJob.js#L98

So, if you were to add an additional check there for selectedTask, you could do something similar. As Armen said, you'd want to default to retry_id of 0, but load that as an optional param as well.

Currently, it finds the job via the jobMap which is keyed by the id. But you could just do a brute-force filter on:

Object.values(jobMap).filter(job => job.task_id === 'xyz');

... and go from there. I don't know that it would be noticeably slower.

This would be great to have. Seems like we could/should eventually migrate to using this rather than the job.id.

Thanks Cam. I'll aim to implement this before we stop ingesting artifacts in the JobDetails table (estimate is by end of April).

I'll need this to link back to treeherder when Push Health switches to Mozci as well.

(In reply to Cameron Dawson [:camd] from comment #8)

I'll need this to link back to treeherder when Push Health switches to Mozci as well.

I'm not following. Can you clarify?

Yeah, that was cryptic. So, at this point, I create links back to Treeherder for each job with a querystring of selectedJob=<job_id>. But when I switch to using Mozci for my back-end data on Push Health, I won't be getting those job_ids anymore. Just the task_id. So it would be great to be able to create those links with a querystring of selectedTask=<task_id>

I created Bug 1630710 for the selectedTask work.

This change is now merged. You can select a job/task with the querystring of selectedTaskRun=<taskId>-<runId>

This was fixed in https://github.com/mozilla/treeherder/pull/6342

for example: https://treeherder.allizom.org/#/jobs?repo=autoland&selectedTaskRun=D80R8Rz3TyKriJENFrcNqA-0

This is the uri you would use: /api/jobs/?task_id=dpOZ-HnyShq4x6rZJzoI3A&retry_id=0

I believe this fixes this bug.