[treeherder] [mozilla-taskcluster] All TaskCluster jobs have machine name of "unknown"

RESOLVED FIXED

Status

RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: emorley, Assigned: garndt)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Broken out from bug 1145062.

This TC submitted job had a machine_name of "unknown":
https://treeherder.mozilla.org/api/project/mozilla-inbound/jobs/7788202/

iirc we just use this as-is from what was submitted to Treeherder.
This is fixed now I believe?
Flags: needinfo?(emorley)
(Reporter)

Comment 3

4 years ago
They're still "unknown" when I look at https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-searchStr=emulator
Flags: needinfo?(emorley)
Component: TaskCluster → General
Product: Testing → Taskcluster
Can we get more details on how to set machine name and what we *should* be putting in there? Maybe workerType?
Component: General → Integration
Flags: needinfo?(emorley)
Summary: B2G JB Emulator opt job has machine name of "unknown" → [treeherder] All TaskCluster jobs have machine name of "unknown"
(Reporter)

Comment 5

3 years ago
(In reply to Selena Deckelmann :selenamarie :selena from comment #4)
> Can we get more details on how to set machine name and what we *should* be
> putting in there? Maybe workerType?

I don't know what workerType is, but that sounds like a type rather than a unique hardware/VM instance name?

machine name for buildbot jobs has values like:
bld-lion-r5-043 
bld-linux64-spot-534
t-w732-ix-149

The machine name is set via the `machine` attribute on a job:
http://treeherder.readthedocs.org/submitting_data.html#job-collections

The idea is to make it easier to spot if one particular instance was the cause of eg a number of JS GC crashes due to bad RAM.

In a more AWS-centric era where we're using spot instances that may not exist for a significant amount of time, this because slightly less useful, however I imagine we'll still have a fair amount of real hardware instances around (eg for OS X builds) and longer-lived AWS instances where this still adds value.
Flags: needinfo?(emorley)
That's a good idea, workerType would be the TC field to use.

Greg, can mozilla-taskcluster get the workerId from the queue for the given task run, and include it when hitting treeherder?

I'm not sure how that code works.

I guess we only principally care about gecko, but are there other components that interface with treeherder? I'm guessing we shouldn't implement this for gaia, as it is now tier 3. Are there any other repositories in treeherder that we feed into (e.g. any repos on github etc?) and if so, where is the treeherder integration on the taskcluster side?
Flags: needinfo?(garndt)
(Assignee)

Comment 7

3 years ago
workerId is already part of the task definition so mozilla-taskcluster can probably insert that easily enough. I can certainly try it out against treeherder staging.
Flags: needinfo?(garndt)
(Assignee)

Comment 8

3 years ago
Created attachment 8713716 [details] [review]
mozilla-taskcluster PR 45
Attachment #8713716 - Flags: review?(emorley)
(Reporter)

Updated

3 years ago
Attachment #8713716 - Flags: review?(emorley) → review+
(Assignee)

Comment 9

3 years ago
merged and deployed.  The instance ID will now be used as the machine name.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Assignee)

Updated

3 years ago
Assignee: nobody → garndt
(Assignee)

Updated

3 years ago
Summary: [treeherder] All TaskCluster jobs have machine name of "unknown" → [treeherder] [mozilla-taskcluster] All TaskCluster jobs have machine name of "unknown"
You need to log in before you can comment on or make changes to this bug.