https://bugzilla.wikimedia.org/show_bug.cgi?id=71602
Bug ID: 71602
Summary: mediawiki_selenium always use the same default xvfb
display 99
Product: Wikimedia
Version: wmf-deployment
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Quality Assurance
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected]
Web browser: ---
Mobile Platform: ---
Our firefox browser tests running on local instances kept complaining of losing
connection to the firefox web driver after 45 seconds. We never really
managed to figure out the issue and went with throttling the browsertests to
ensure that only one run per instance (
https://gerrit.wikimedia.org/r/#/c/155337/ ).
Timo proposed a patch to add chromium and a xvfb server on the contint slaves
which propose to maintain an xvfb service on display port 99. That is what
triggered the race condition warning to me.
In mediawiki_selenium we use ruby gems headless defaults:
require "headless"
headless = Headless.new
headless.start
Then destroy it:
at_exit do
headless.destroy
end
Looking at headless code (
https://github.com/leonid-shevtsov/headless/blob/master/lib/headless.rb ) the
default are:
* display port 99
* auto picking disabled (since display port is set)
* reuses display
When the first test start, that boot an xvfb on display port 99. A second test
starting in parallel will end up reusing the same display. Imho that would
cause a bunch of race conditions between the two browsers being run.
mediawiki_selenium should probably be invoked with:
Headless.new(autopick: true, reuse: false)
We could have that tweakable via env variable such as HEADLESS_DISPLAY,
HEADLESS_AUTOPICK and HEADLESS_REUSE.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
