Closed Bug 1093012 Opened 10 years ago Closed 9 years ago

TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/mozmill/content-policy/test-plugins-policy.js | test-plugins-policy.js::setupModule

Categories

(Release Engineering :: General, defect)

All
macOS
defect
Not set
normal

Tracking

(firefox45 fixed, firefox46 fixed, firefox47 fixed)

RESOLVED FIXED
Tracking Status
firefox45 --- fixed
firefox46 --- fixed
firefox47 --- fixed

People

(Reporter: aleth, Assigned: aleth)

References

Details

(Keywords: intermittent-failure)

Attachments

(3 files, 3 obsolete files)

also TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/mozmill/content-tabs/test-plugin-blocked.js | test-plugin-blocked.js::test_blocklisted_plugin_notification TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/mozmill/content-tabs/test-plugin-crashing.js | test-plugin-crashing.js::setupModule TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/mozmill/content-tabs/test-plugin-outdated.js | test-plugin-outdated.js::setupModule
Do you remember what fixed these failures? They are still broken on esr38.
Flags: needinfo?(mkmelin+mozilla)
No sorry.
Flags: needinfo?(mkmelin+mozilla)
Actually may not be fixed, still showing up in OSX debug on c-c.
Also fails on OSX opt, but not when run locally. These are all EXCEPTION: plugin is null which is from get_test_plugin() in test-content-tab-helpers.js
(In reply to aleth [:aleth] from comment #7) > Also fails on OSX opt, but not when run locally. > > These are all > EXCEPTION: plugin is null > > which is from get_test_plugin() in test-content-tab-helpers.js The only plugin that is found is the Default Browser Helper. Maybe we are not packaging the test plugin for some reason on OS X?
An OSX local build finds (on running the mozmill test) the following plugins: * Default Browser Helper * Java Applet Plug-in * Shockwave Flash * Java Test Plug-in * Flash Test Plug-in * Second Test Plug-in * Test Plug-in These are located in objdir/dist/plugins and objdir/_tests/mozmill/mozmillprofile/plugins.
(In reply to aleth [:aleth] from comment #9) > objdir/_tests/mozmill/mozmillprofile/plugins. This is generated when the mozmill test is run, the plugin dir location is passed via a flag (testsuite-targets.mk).
In automation, mozmill is run by runtest.py, called by runtestlist.py. Adding some logging here shows that the PLUGINS_PATH is not set, and so the plugins are not copied to the mozmillprofile, causing the failure.
This sets the plugins-path command line parameter for runtestlist.py, which should hopefully resolve the problem. (It's unfortunately not possible to test this on try-comm-central.)
Attachment #8719077 - Flags: review?(cmanchester)
Assignee: nobody → aleth
Status: NEW → ASSIGNED
Comment on attachment 8719077 [details] [diff] [review] Set plugins-path for mozmill tests run via mozharness Review of attachment 8719077 [details] [diff] [review]: ----------------------------------------------------------------- This looks reasonable, but I think jlund should review here.
Attachment #8719077 - Flags: review?(cmanchester)
Attachment #8719077 - Flags: review?(jlund)
Comment on attachment 8719077 [details] [diff] [review] Set plugins-path for mozmill tests run via mozharness Review of attachment 8719077 [details] [diff] [review]: ----------------------------------------------------------------- also looks good to me. that's too bad this can't be tested via comm-try :(
Attachment #8719077 - Flags: review?(jlund) → review+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 47.0
Exception: Plugins path "/builds/slave/test/build/application/Daily.app/Contents/Resources/plugins" does not exist. TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during directory run
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
On Linux, this patch works: PLUGINS_PATH is /builds/slave/test/build/application/thunderbird/plugins and the plugins are indeed found there. Not sure what goes wrong on OSX at this point (some universal build issue?), or why this failure didn't occur for Linux before the plugin path was set.
These plugins are packaged in common.tests.zip/bin/plugins, both for Linux and Mac. So the suspicion has to be that they aren't copied to the right place on Mac.
OSX mozmill 20:24:51 INFO - Running main action method: run_tests 20:24:51 INFO - mkdir: /builds/slave/test/build/application/Daily.app/Contents/MacOS/plugins 20:24:51 INFO - copying tree: /builds/slave/test/build/tests/bin/plugins to /builds/slave/test/build/application/Daily.app/Contents/MacOS/plugins Linux mozmill 09:38:26 INFO - mkdir: /builds/slave/test/build/application/thunderbird/plugins 09:38:26 INFO - copying tree: /builds/slave/test/build/tests/bin/plugins to /builds/slave/test/build/application/thunderbird/plugins OSX xpcshell 03:38:17 INFO - Running main action method: run_tests 03:38:17 INFO - mkdir: /builds/slave/test/build/application/Daily.app/Contents/Resources/plugins 03:38:17 INFO - copying tree: /builds/slave/test/build/tests/bin/plugins to /builds/slave/test/build/application/Daily.app/Contents/Resources/plugins
I think this should do it. I'm not sure 'components' is actually required for mozmill, and has nothing to do with this bug, but it is present for xpcshell and so its absence for mozmill seems dubious.
Attachment #8721712 - Flags: review?(jlund)
Attachment #8719077 - Attachment is obsolete: true
Attachment #8719077 - Attachment is obsolete: false
Comment on attachment 8721712 [details] [diff] [review] Ensure plugins and extensions are placed in Contents/Resources on OSX for mozmill tests Review of attachment 8721712 [details] [diff] [review]: ----------------------------------------------------------------- this logic looks very similar to preflight_xpcshell()[1] do you think we could rip this out into some common helper method? also, do you think we will need a mozmill equivalent bin copy that is similar to xpcshell: shutil.copy2(os.path.join(dirs['abs_test_bin_dir'], c['xpcshell_name']), os.path.join(abs_app_dir, c['xpcshell_name'])) [1] https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/desktop_unittest.py#517
Attachment #8721712 - Flags: review?(jlund) → review+
(In reply to Jordan Lund (:jlund) from comment #24) > also, do you think we will need a mozmill equivalent bin copy that is > similar to xpcshell: > shutil.copy2(os.path.join(dirs['abs_test_bin_dir'], c['xpcshell_name']), > os.path.join(abs_app_dir, c['xpcshell_name'])) I don't think so - there doesn't seem to be any mozmill equivalent to the xpcshell binary in common.tests.zip/bin (and if there was much more should have been broken).
Attachment #8721712 - Attachment is obsolete: true
Attachment #8722253 - Attachment is obsolete: true
Attachment #8722253 - Flags: review?(jlund)
Attachment #8722255 - Attachment is obsolete: true
Attachment #8722255 - Flags: review?(jlund)
Comment on attachment 8722467 [details] [diff] [review] Ensure plugins and extensions are placed in Contents/Resources on OSX for mozmill tests Review of attachment 8722467 [details] [diff] [review]: ----------------------------------------------------------------- ooo .. I like this much more! :)
Attachment #8722467 - Flags: review?(jlund) → review+
Comment on attachment 8722467 [details] [diff] [review] Ensure plugins and extensions are placed in Contents/Resources on OSX for mozmill tests if it doesn't break xpcshell on try, ship-it!
https://hg.mozilla.org/integration/mozilla-inbound/rev/13f2bf958d0f2cd816b24aaebf4e2237263d4638 Bug 1093012 - Ensure plugins and extensions are placed in Contents/Resources on OSX for mozmill tests. r=jlund
Component: Testing Infrastructure → Mozharness
Product: Thunderbird → Release Engineering
QA Contact: jlund
Target Milestone: Thunderbird 47.0 → ---
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Mozmill is finally green. Changing the component to be able to request uplift.
Component: Mozharness → General Automation
QA Contact: jlund → catlee
Comment on attachment 8719077 [details] [diff] [review] Set plugins-path for mozmill tests run via mozharness Approval Request Comment [Feature/regressing bug #]: Makes mozmill tests run properly on OS X [User impact if declined]: Test-only changes [Describe test coverage new/current, TreeHerder]: OS X mozmill now green on c-c [Risks and why]: low (change affects only mozmill test harness)
Attachment #8719077 - Flags: approval-mozilla-beta?
Attachment #8719077 - Flags: approval-mozilla-aurora?
Attachment #8722467 - Flags: approval-mozilla-beta?
Attachment #8722467 - Flags: approval-mozilla-aurora?
Comment on attachment 8719077 [details] [diff] [review] Set plugins-path for mozmill tests run via mozharness Improve the testsuite, taking it. Should be in 45 beta 10
Attachment #8719077 - Flags: approval-mozilla-beta?
Attachment #8719077 - Flags: approval-mozilla-beta+
Attachment #8719077 - Flags: approval-mozilla-aurora?
Attachment #8719077 - Flags: approval-mozilla-aurora+
Attachment #8722467 - Flags: approval-mozilla-beta?
Attachment #8722467 - Flags: approval-mozilla-beta+
Attachment #8722467 - Flags: approval-mozilla-aurora?
Attachment #8722467 - Flags: approval-mozilla-aurora+
has problems uplifting, could you take a look ? grafting 330231:13f2bf958d0f "Bug 1093012 - Ensure plugins and extensions are placed in Contents/Resources on OSX for mozmill tests. r=jlund" merging testing/mozharness/scripts/desktop_unittest.py warning: conflicts while merging testing/mozharness/scripts/desktop_unittest.py! (edit, then use 'hg resolve --mark') abort: unresolved conflicts, can't continue (use hg resolve and hg graft --continue)
Flags: needinfo?(aleth)
Attachment #8723624 - Attachment description: Ensure plugins and extensions are placed in Contents/Resources on OSX for mozmill tests → Ensure plugins and extensions are placed in Contents/Resources on OSX for mozmill tests -- mozilla-aurora version
Flags: needinfo?(aleth)
Flags: needinfo?(cbook)
Aleth, why don't you just check it in? It's been reviewed and approved, so surely that covers an adaption to Aurora.
Only believe only sheriffs check in things for the m-c repos other than inbound (and the like).
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: