Mozharness desktop unittests don't use the in tree mozharness config

RESOLVED FIXED

Status

Release Engineering
Mozharness
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: ahal, Assigned: ahal)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mozharness])

Attachments

(1 attachment, 1 obsolete attachment)

This is because they selectively extract tests.zip and therefore the config directory doesn't exist. See https://hg.mozilla.org/build/mozharness/file/27b230a75983/scripts/desktop_unittest.py#l270
Created attachment 768689 [details] [diff] [review]
Patch 1.0 - also extract the config directory
Attachment #768689 - Flags: review?(aki)

Comment 2

4 years ago
Comment on attachment 768689 [details] [diff] [review]
Patch 1.0 - also extract the config directory

Does this config/ directory exist on all trees?  (This patch will affect all trees except maybe esr17, and will most likely cause burning without the config/ dir.)
Attachment #768689 - Flags: review?(aki) → review+
Oh good call. I just checked, it's on b2g18* but not release (or aurora or beta probably). I guess my options are to either land the tree_config patch everywhere including release, or just make desktop mochitests extract the whole zip file :(
fwiw I'm totally fine having to push this manually to try to let bug 872164 ride the trains normally
(In reply to :Felipe Gomes from comment #4)
> fwiw I'm totally fine having to push this manually to try to let bug 872164
> ride the trains normally

Nah, this patch is against mozharness, so no way to push it to try. The problem is that all test jobs across all branches use the same mozharness scripts, which ironically is the reason we wanted in-tree mozharness scripts in the first place
So I did some digging around and it looks like when a match like this isn't found the return code is always 11. See http://www.info-zip.org/mans/unzip.html#DIAGNOSTICS

I verified this locally, but also pushed a patch to ash-mozharness to make sure it works on all platforms:
http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness/rev/a0e7aecd9241

Waiting for results here:
https://tbpl.mozilla.org/?tree=Ash&rev=10dcc800e67d
Created attachment 770943 [details] [diff] [review]
Patch 2.0 - extract config and allow ret code 11 from tests unzip

So you're right that the old patch would have caused bustage where "config" didn't exist. By allowing a return code of 11 though, this seems to work. I tested by adding a junk folder to the extract list on mozharness ash: http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness/rev/7cb05e1d1695
Attachment #768689 - Attachment is obsolete: true
Attachment #770943 - Flags: review?(aki)

Comment 8

4 years ago
Comment on attachment 770943 [details] [diff] [review]
Patch 2.0 - extract config and allow ret code 11 from tests unzip

Cool, good to see success_codes isn't a one trick pony.
Attachment #770943 - Flags: review?(aki) → review+
https://hg.mozilla.org/build/mozharness/rev/703427b7e1ee

Still needs to be merged to production before live.
in production
Felipe, your previous patch should work now. I have a try run here to test it out:
https://tbpl.mozilla.org/?tree=Try&rev=f1e83b72d873

(if you see --console-level=DEBUG in the arguments that means it's working).
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Thanks Andrew! I had also sent another try run earlier today and verified it works!
https://tbpl.mozilla.org/?tree=Try&rev=5d41b5109c3c
Product: mozilla.org → Release Engineering

Updated

3 years ago
Component: General Automation → Mozharness
Blocks: 1067535
You need to log in before you can comment on or make changes to this bug.