All users were logged out of Bugzilla on October 13th, 2018
58 bytes, text/x-review-board-request
58 bytes, text/x-review-board-request
Stas ran into a task that was failing to run mochitest on a one-click-loaner because it was missing mozinfo data. After looking at the task there was no "mozinfo.json" file under: /home/worker/workspace/build/tests This file should normally be packaged in the tests.zip, looks like something changed to regress this.
Assignee: nobody → ahalberstadt
Status: NEW → ASSIGNED
I can't figure out what regressed this, and now I'm questioning how this ever worked in the first place (though it definitely did)... Anyway, these two patches get things working again for me. I think stas was still having problems with the mochitest harness finding his test, but I think it's best to file a new bug for that if it is still a problem after this.
Comment on attachment 8803330 [details] Bug 1311723 - Fix wrong binary_path in desktop_unittest.py configs, https://reviewboard.mozilla.org/r/87638/#review86600
Attachment #8803330 - Flags: review?(armenzg) → review+
Thanks for looking into this, Andrew! I'll be happy to test running mochitests in the loaner once this lands and will file a new bug if the problem persists.
Comment on attachment 8803329 [details] Bug 1311723 - Fix missing mozinfo.json when running interactive loaners, https://reviewboard.mozilla.org/r/87636/#review86598 What is the purpose of mozinfo.json? I don't really know the implications of adding this file to the mix.
Attachment #8803329 - Flags: review?(armenzg) → review+
Comment on attachment 8803329 [details] Bug 1311723 - Fix missing mozinfo.json when running interactive loaners, https://reviewboard.mozilla.org/r/87636/#review86598 It's needed to filter the manifests among other things. I'm not really sure how the real automation jobs are getting it, but they must be otherwise everything would fail.
Every test package packages its own copy of mozinfo.json currently (kinda dumb): https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/action/test_archive.py ...and each harness just looks for it next to the main harness script (or any parent dir): https://dxr.mozilla.org/mozilla-central/rev/f0f1aaf051d6798e1e73d1feee07ca847333167a/testing/mochitest/runtests.py#819 We could drop that for harnesses when we get them running from the source checkout. Assuming your interactive loaner script is unpacking the mochitest.zip as usual I would expect there to be a mozinfo.json under `tests/mochitest`. However! If you're running the runtests.py script from inside the source checkout instead of the test package that would definitely break.
Oh right! I forgot it was under tests/mochitest and not the root of the package.. And here's why it's failing: https://dxr.mozilla.org/mozilla-central/source/testing/mochitest/mach_test_package_commands.py#64 That should just be 'here' instead of 'dirname(here)'. I'm still confused about how this was working before though. I'll get a new patch up instead of the old one.
You added that code in bug 1300163, so I assume that's what broke it :) https://hg.mozilla.org/mozilla-central/rev/dd6f0732c260#l1.59
Well that was when I last tested it and I'm pretty sure it was working.. but I must of tested differently or mis-remembered something.
Attachment #8803329 - Attachment is obsolete: true
Comment on attachment 8803506 [details] Bug 1311723 - Look for mozinfo.json in the correct place when running interactive loaners, https://reviewboard.mozilla.org/r/87738/#review86724
Attachment #8803506 - Flags: review?(armenzg) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/3e9509be9108 Fix wrong binary_path in desktop_unittest.py configs, r=armenzg https://hg.mozilla.org/integration/autoland/rev/85832226cbd7 Look for mozinfo.json in the correct place when running interactive loaners, r=armenzg
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.