1018802 - Prevent Windows test slaves from running jobs if the resolution is less than it is supposed to be

Status: RESOLVED DUPLICATE of bug 1190868

(Infrastructure & Operations Graveyard :: CIDuty, task)

Description

[Phil Ringnalda (:philor)]

We have a preflight mouse_and_screen_resolution.py script that sets and checks the resolution on Win7 test jobs. We desperately need it for Win8 test jobs. Bug 977561? That's not a test bug, that's what happens when the test runs on a Win8 slave running at 1024x768. Bug 1003614? That's not a test bug, that's 1024x768. Are there more? Don't know.

We need a Win8 version, since apparently it's now anyone's guess whether a reimaged Win8 slave will actually retain its 1900x1600 resolution, or revert to 1024x768.

Comment 1

[Ed Morley [:emorley]]

Chris, don't suppose you can find someone who's up for taking this? :-)

Comment 2

[Ryan VanderMeulen [:RyanVM]]

While that is indeed not great, I'm not sure why tests get a pass for failing if not run at a certain resolution. That seems pretty weak to me.

Comment 3

[Phil Ringnalda (:philor)]

Well, two minimum resolutions exist, whether we like it or not: there's the minimum resolution that will render the browser chrome while still allowing enough window to render our largest content thingy (perhaps videocontrols, I don't have any idea), below which tests aren't going to work whether or not we spend several weeks altering the status quo and requiring every test that needs its content rendered and clickable to shove its content up into the smallest amount of window real estate possible and scroll it around between individual subtests of different parts of the content, and there's the practical minimum resolution that results from needing to be above a certain resolution to get accelerated graphics, so we have to run the test slaves above that resolution, so resolutions lower than that will not be tested, so people are more than welcome to file bugs about "I can't run your test on my netbook," and good luck to them.

I don't mind either way if someone wants to work on the former, or if along the way they also want to drop the resolution that we run slaves at to the lowest for each platform which will still give us accelerated graphics, but after all that there will still be a minimum resolution at which we can run a slave in automation, and given the way we constantly get slaves running at a resolution other than what we intend, there will still be a need to have a preflight script which checks the resolution and doesn't run the job if it can't be set to that.

Comment 4

[Chris Cooper [:coop] (he/him)]

(In reply to Ed Morley [:edmorley UTC+0] from comment #1)
> Chris, don't suppose you can find someone who's up for taking this? :-)

I had someone lined up for this (and other) Windows test platform work, but they're going on PTO. 

I'm going to talk to catlee about maybe getting the intern who's working on pre-flight checks to start pounding through the actual list of checks once the framework is done (bug 712206).

Comment 5

[Ed Morley [:emorley]]

(In reply to Chris Cooper [:coop] from comment #4)
> I'm going to talk to catlee about maybe getting the intern who's working on
> pre-flight checks to start pounding through the actual list of checks once
> the framework is done (bug 712206).

Thank you :-)

Comment 6

[Chris Cooper [:coop] (he/him)]

No reason to fix this just for Windows 8. Let's add a runner pre-flight task to verify the resolution on all Windows testers. I've started hacking on mouse_and_screen_resolution.py to this end.

Comment 7

[Chris Cooper [:coop] (he/him)]

...and now I find the other bug for this.