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 <[email protected]> wrote: > On 9 August 2014 21:04, Bryan Davis <[email protected]> wrote: > > > On Sat, Aug 9, 2014 at 6:52 PM, Brion Vibber <[email protected]> > > 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. > > [email protected] | @jdforrester > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Dan Duvall Automation Engineer Wikimedia Foundation <http://wikimediafoundation.org> _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
