TEST-UNEXPECTED-FAIL | c:\slave\test\build\tests\xpcshell\tests\toolkit\mozapps\update\tests\unit_service_updater\bootstrapSvc.js | test failed (with xpcshell return code: 0), see following log: TEST-UNEXPECTED-FAIL | c:/slave/test/build/tests/xpcshell/tests/toolkit/mozapps/update/tests/unit_service_updater/head_update.js | test registry key exists but this test can only run on systems with the maintenance service installed. - See following stack: https://tbpl.mozilla.org/php/getParsedLog.php?id=33509068&tree=Date
Note: we can't run these tests because the Win64 builds are not signed. Bug 711210
Chris, I noticed that the updater service tests are running (failing as expected) on Date Win64 https://tbpl.mozilla.org/php/getParsedLog.php?id=33509068&tree=Date even though they shouldn't be since MOZ_MAINTENANCE_SERVICE shouldn't be defined. http://mxr.mozilla.org/mozilla-central/source/browser/confvars.sh#11 If I go back to 1/14 they didn't run https://tbpl.mozilla.org/php/getParsedLog.php?id=33013529&tree=Date I haven't experienced this locally though I admit that I haven't tried with the in tree mozconfig for Win64. Do you know of any changes that would have made MOZ_MAINTENANCE_SERVICE end up being defined?
Summary: Disable throwing on Win64 service test check until we have the service on Win64 → Service tests should not be running on Win64
I downloaded the zip and the installer both of which did not have the maintenance service. I downloaded the tests and none of the maintenance service tests were present. There was the maintenance service test directory (unit_service_updater) due to the head file being copied there but no xpcshell.ini or test files. I filed bug 963848 to not copy the head file to that directory unless the maintenance service is built. Perhaps that is why.
Brian, any idea how this is happening? https://tbpl.mozilla.org/?tree=Date&rev=7b838c623ebb
So if there's no define this shouldn't run. That means that it's either defined or something else is going on like the directory is being re-used with pre-existing files. Sorry no ideas come to mind. This is intermittent right?
It doesn't appear to be intermittent when looking at the Date tbpl. I suspect it might have something to do with the way tests are run on the build systems... perhaps it is just looking inside directories.
Seems like this is always evaluating to true if not intermittent. http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/tests/moz.build#13 But that doesn't explain why the zip you downloaded didn't contain the test files.
gps, any idea what could be going on here?
Flags: needinfo?(catlee) → needinfo?(gps)
Try builds are clobbers, so you shouldn't have any issues from old builds. AFAIK, nothing changed in test packaging land recently. MOZ_MAINTENANCE_SERVICE must be defined somehow. Or, the test manifests beind defined in toolkit/mozapps/update/tests/moz.build outside of the |if CONFIG['MOZ_MAINTENANCE_SERVICE']| might be pulling in unwanted tests. I didn't look too deeply on which tests were failing.
If MOZ_MAINTENANCE_SERVICE were defined I would expect the test files to show up in the zip file for the tests and they aren't there. Also, this is only happening on the Date branch where we are trying to get the tests on Win64 to pass.
This doesn't happen on the non VM Win64 builders so I suspect it has something to do with the VMs though with the VMs having difficulty the last run didn't run tests so it might have self corrected. https://tbpl.mozilla.org/?tree=Date&rev=c0d4a08e2d80
Assignee: robert.strong.bugs → nobody
I didn't realize that the Win64 VMs were running tests on both the 32 and 64 bit builds. I suspect the problem is that the maintenance service isn't installed on the Win64 VMs.
Summary: Service tests should not be running on Win64 → Win64 fails running service tests when testing 32 bit
I think this is a machine config problem should it be moved to a different category for RelEng to investigate?
I plan on doing so after we discuss whether Win64 VMs will be used.
Status: ASSIGNED → NEW
I think this can probably be marked Resolved | Invalid
I agree since the build systems that were exhibiting this don't appear to be in use anymore.
4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.