Closed Bug 1153774 Opened 9 years ago Closed 9 years ago

Teach mozharness to detect the emulator type (arm or x86) implicitly

Categories

(Taskcluster :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hsinyi, Assigned: jdai)

References

Details

Attachments

(1 file, 2 obsolete files)

This was originally a clone of bug 1144970 comment 5.
John, as you have been investigating this, I am assigning this to you. If you need any help, please let me know, thank you.
Assignee: nobody → jdai
Is there a way let test cluster point to my mozharness? I have a patch[1] let mozharness self detect emulator type, and I changed |MOZHARNESS_REPOSITORY| to my mozharness location[2]. When test cluster running each test, the docker environment doesn't checkout my repository[3][4].

[1]https://treeherder.allizom.org/#/jobs?repo=try&revision=214e23796834
[2]https://hg.mozilla.org/users/jdai_mozilla.com/mozharness
[3]https://s3-us-west-2.amazonaws.com/taskcluster-public-artifacts/ECOM24EjQYyV252kjt3_HQ/0/public/logs/live_backing.log
[4]+ buildbot_step 'Checkout mozharness' tc-vcs checkout mozharness https://hg.mozilla.org/build/mozharness https://hg.mozilla.org/build/mozharness default
Flags: needinfo?(jlal)
[Tracking Requested - why for this release]:
https://dxr.mozilla.org/mozilla-central/source/testing/taskcluster/mach_commands.py#198

^ You can edit this here in your try commit and it will use this mozharness instead (you need to push to some user repo or github fork)
Flags: needinfo?(jlal)
pcshell tests are able to pass tests, but mochitest and reftest hit others issues.

Test cluster result:
https://treeherder.allizom.org/#/jobs?repo=try&revision=55cc7dace3c3

Mozharness detects the emulator 'x86' type log:
https://s3-us-west-2.amazonaws.com/taskcluster-public-artifacts/NATEZVP6RAqEmjrr9O4Zcg/0/public/logs/live_backing.log
Attachment #8595705 - Flags: review?(pmoore)
Comment on attachment 8595705 [details] [diff] [review]
Mozharness detects the emulator type implicitly.

It looks sane to me, but I'd prefer Andrew to take a look, as he knows this code much better than me.

Thanks,
Pete
Attachment #8595705 - Flags: review?(pmoore) → review?(ahalberstadt)
Comment on attachment 8595705 [details] [diff] [review]
Mozharness detects the emulator type implicitly.

Review of attachment 8595705 [details] [diff] [review]:
-----------------------------------------------------------------

Seems reasonable to me. Will this also work with emulator-jb/kk/l if we ever turn on tests there?
Attachment #8595705 - Flags: review?(ahalberstadt) → review+
(In reply to Andrew Halberstadt [:ahal] from comment #7)
> Comment on attachment 8595705 [details] [diff] [review]
> Mozharness detects the emulator type implicitly.
> 
> Review of attachment 8595705 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Seems reasonable to me. Will this also work with emulator-jb/kk/l if we ever
> turn on tests there?

Currently, no tests are run on emulator-jb, and AFAIK there's no plan to maintain emulator-jb or enable tests on that. Once we have emulator-kk tests on treeherder stable enough, we are going to deprecate emulator (ics) and emulator-jb. So I'd suggest we don't put resource on that.

Regarding emulator-L, it's definitely the next target, but for now, tests on emulator-l haven't be supported yet, and few efforts have been put on that. Do you think we could just verify emulator-ics and emlator-kk work well at the moment, and fix emulator-l problems later if any when we really work on that? Thank you!
I put on test cluster result, it works on emulator-ics, emulator-kk and emulator-x86-kk.
If you don't have any concern, I want to check-in this patch. Thank you.
Flags: needinfo?(ahalberstadt)
Yep, go ahead, that's what the r+ was for :). I was just wondering is all (I didn't even know we were already running tests on kk).
Flags: needinfo?(ahalberstadt)
Keywords: checkin-needed
1. Carry on r+ flag.
2. Patch add reviewer.
Attachment #8595705 - Attachment is obsolete: true
Attachment #8597762 - Flags: review+
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #14)
> https://hg.mozilla.org/build/mozharness/rev/2e1bac823044

Hi Ryan,
As the patch has been pushed to build/mozharness, is it able to close this bug? Or anything else we need to do before closing it? Thank you!

This is the first time the team touches the mozharness bug, so sorry that if the question sounds too trivial :P
Flags: needinfo?(ryanvm)
Our test infra uses an in-tree pointer to a fixed revision of mozharness:
http://hg.mozilla.org/mozilla-central/file/4b9b12c248dc/testing/mozharness/mozharness.json

So you'll need to get that pointer updated to a newer rev for your change to be live in production.
Flags: needinfo?(ryanvm)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #16)
> Our test infra uses an in-tree pointer to a fixed revision of mozharness:
> http://hg.mozilla.org/mozilla-central/file/4b9b12c248dc/testing/mozharness/
> mozharness.json
> 
> So you'll need to get that pointer updated to a newer rev for your change to
> be live in production.

Got it, thanks for the explanation.

Hi John,
Please help follow the remaining part up.
Attached patch Update mozharness revision. (obsolete) — Splinter Review
Keywords: checkin-needed
Comment on attachment 8599736 [details] [diff] [review]
Update mozharness revision.

Hi Ryan,

Can you help me review this patch? Thank you!
Attachment #8599736 - Flags: review?(ryanvm)
Keywords: checkin-needed
Comment on attachment 8599736 [details] [diff] [review]
Update mozharness revision.

Review of attachment 8599736 [details] [diff] [review]:
-----------------------------------------------------------------

Not quite that simple :) - We need to stay on the production branch (which includes changes other than yours).
Attachment #8599736 - Flags: review?(ryanvm) → review-
Comment on attachment 8599736 [details] [diff] [review]
Update mozharness revision.

I went ahead and did the bump since it had been nearly 2 weeks since it was last done.
https://hg.mozilla.org/integration/mozilla-inbound/rev/da60d90cc685
Attachment #8599736 - Attachment is obsolete: true
Hi Ryan,

Thanks for helping me did the bump :) Is it able to close this bug? Do I need to provide anything before closing this bug? Thank you.
Flags: needinfo?(ryanvm)
You should probably verify that things are working as expected in production now, but feel free to resolve the bug if you're satisfied.
Flags: needinfo?(ryanvm)
Hi John,
The treeherder result looks as expected to me. Could you please confirm and update the bug status accordingly? thank you.
Flags: needinfo?(jdai)
After I confirmed the treeherder result, it looks as expected to me.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(jdai)
Resolution: --- → FIXED
Component: TaskCluster → General
Product: Testing → Taskcluster
Target Milestone: --- → mozilla41
Version: unspecified → Trunk
Resetting Version and Target Milestone that accidentally got changed...
Target Milestone: mozilla41 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: