I know that in some of these cases, it was necessary to provision the optional dependencies to keep many browser tests from falsely failing and consequently losing their utility. Roles for extensions such as VE and MF that re-implement and test a broad set of interfaces may seem particularly bloated due to these dependencies.
We'd been exploring alternatives to this kind of brute-force setup over the past weeks and finally settled on a system by which browser-test features are annotated to declare their extension dependencies[1]; the runner skips features where dependencies aren't met and omits warnings to the user about why—which extensions are not installed/enabled.[2] As of Friday, support for these tags is available as part of mediawiki_selenium 0.3.0![3] (I'll be updating the QA wiki articles today and announcing availability to the QA list.)
Given this new dependency system, it's no longer necessary to hardwire roles solely to keep browser-test suites happy, so let's pair 'em down and welcome our new Hiera overlords.
[1]: http://lists.wikimedia.org/pipermail/mobile-l/2014-July/007647.html [2]: http://lists.wikimedia.org/pipermail/mobile-l/2014-August/007773.html [3]: https://gerrit.wikimedia.org/r/#/c/151802/
On Mon, Aug 11, 2014 at 2:13 AM, James Forrester jforrester@wikimedia.org wrote:
On 9 August 2014 21:04, Bryan Davis bd808@wikimedia.org wrote:
On Sat, Aug 9, 2014 at 6:52 PM, Brion Vibber bvibber@wikimedia.org wrote:
Agreed; "mobilefrontend" and "mobilefrintend-tests" would probably work
as
a pair, same with cirrus etc. however the list of roles is getting
kinda
long and may need a better display with descriptions and search in the future... If we add lots more extensions *and* their optional tests or configs it's going to be a lot. :)
I have started to work on some patches that will change the way that we manage the collection of enabled roles (hiera for the puppet nerds in the audience). When I was talking to Ori about this he had an idea that I dismissed initially, but which might actually be a cool thing to do. His idea was to make the role toggling be manageable via a web interface on the VM's webserver. I think his actual idea may have involved making a MW extension that managed the entire local hiera settings file. I'm not sure that I'm in love with the wikiification idea, but if we want a cross-platform interface with search, sort and grouping... a web app seems like a reasonable thing we could create.
That sounds like it could be really neat.
Right now we only one VisualEditor role which doesn't exactly match any particular wiki, but although we could create lots of sub-roles to enable and disable certain features and alter their configuration, it's not clear if that's a good approach to take (as well as being rather delicate and confusing for others). Not sure if you had in mind sub-roles as well as a more simple list of checkboxen for each role, but maybe that could be a longer-term enhancement if we do go down this route.
J.
James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l