974458 - Qualify stability of Mozmill tests for ms locale

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Infrastructure, defect)

Description

[u279076]

We have a new locale (ms) on Aurora and Beta as of yesterday. We need to be able to support this new locale via automation. I can take care of Beta via on-demand tests but we'll want daily testruns running for Aurora builds.

I'm reporting this bug to track the work needed to implement daily coverage of this locale.

Comment 1

[u279076]

Mihaela, as Henrik's team is busy with things like Metro, this is something I'd like you to work on.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Anthony, this is a mozmill-ci issue so it doesn't fit into this component. As I have mentioned in the meeting we should first do some manual spotchecks how stable this locale is. I don't think that it is worth adding it as default locale to test for Aurora. We haven't done this with any other new locale yet. We are still waiting for the rotation script, so that we can cover all locales and not only individual ones.

So I would suggest that Mihaela executes testruns for ms and we get failures logged. I believe there might be failures, and it could take a while to get them fixed.

I move this to infrastructure for now.

Comment 3

[u279076]

(In reply to Henrik Skupin (:whimboo) from comment #2)
> So I would suggest that Mihaela executes testruns for ms and we get failures
> logged. I believe there might be failures, and it could take a while to get
> them fixed.

Yup, I've already asked that Mihaela does this as her first step.

Comment 4

[Mihaela Velimiroviciu (:mihaelav)]

I triggered the jobs for addons, l10n, functional, remote and update testruns on latest Aurora builds.
Addons, Remote and Update runs: all pass
L10n run - failure: bug 974842 Multiple access keys used in preferences dialog for ms locale
Functional - failure: bug 974902 [ms] CTRL+a opens page souce instead of selecting all content

Comment 5

[u279076]

Thanks Mihaela, I think that's sufficient to call this resolved. Bug 974902 does not need to block this bug I think.

Comment 6

[Dave Hunt [:davehunt] [he/him] ⌚BST]

I noticed two jobs on our staging instance waiting for a node that doesn't exist. The node label expected was 'linux&&ubuntu&&12.04&&64' instead of 'linux&&ubuntu&&12.04&&64bit'. The locale was 'ms' so I assume this is related to this bug. I will now cancel these jobs, as they'll never run.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So with the other dependent issue fixed, is this locale working now for our tests? Or are there any other issues left? If not we can close it.

Comment 8

[Mihaela Velimiroviciu (:mihaelav)]

It looks like new failures appeared:
* l10n testrun, across all platforms: http://mozmill-crowd.blargon7.com/#/l10n/reports - logged bug 995203
failed 	/testAccessKeys/test1.js 	testPrefWindowAccessKeys 	

    accessKey: "k" found in: label#historyModeLabel, checkbox#acceptCookies
    accessKey: "p" found in: checkbox#privateBrowsingAutoStart, button#cookieExceptions
    accessKey: "k" found in: label#historyModeLabel, checkbox#acceptCookies
    accessKey: "p" found in: checkbox#privateBrowsingAutoStart, button#cookieExceptions

Functional, remote and addons testruns have no failures:
http://mozmill-crowd.blargon7.com/#/functional/reports?app=All&branch=29.0&platform=All&from=2014-04-11&to=2014-04-11
http://mozmill-crowd.blargon7.com/#/remote/reports?app=All&branch=29.0&platform=All&from=2014-04-11&to=2014-04-11
http://mozmill-crowd.blargon7.com/#/addons/reports?app=All&branch=All&platform=All&from=2014-04-11&to=2014-04-11
http://mozmill-crowd.blargon7.com/#/addons/reports?app=All&branch=All&platform=All&from=2014-04-11&to=2014-04-11

Comment 9

[u279076]

Is this bug still something worth doing or should we just close it?

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The one and only remaining dependency is for access keys in l10n tests which we do not run at the moment. So I think all is fine here.