[15:56:04] https://tools.wmflabs.org/sal/thisprojectdoesn%27texist [15:57:53] heh yeah. no validation, just irc message scraping [15:58:38] in -labs "!log any-damn-thing-you-want Foo" will end up in the index [16:00:40] :) [16:00:57] I'm impressed the ' wasn't stripped somewhere along the line [17:03:54] ostriches: Are you going to be in the office for release fun today? [18:17:17] legoktm: https://gerrit.wikimedia.org/r/#/c/229981/2 [18:23:04] AaronSchulz: https://gerrit.wikimedia.org/r/#/c/227662/ :) [18:26:48] legoktm: https://gerrit.wikimedia.org/r/#/c/230251/ easy [18:27:09] AaronSchulz: release notes? [18:27:34] sure, though I'd be shocked if anyone used that [21:36:12] Does anyone know what happened to the browsertests role in mediawiki-vagrant? [21:36:36] It's mentioned at https://www.mediawiki.org/wiki/Quality_Assurance/Browser_testing/Running_tests, but seems to be missing. [21:36:39] it got folded into the various roles that had things to test I think [21:37:56] yeah. that's old docs. The browser tests for everything were in one repo at one point and separate from the features that were tested [21:38:05] this changed a year ago at least [21:38:09] there's a patch to move them back into a role, but i need to fix it up [21:38:18] https://gerrit.wikimedia.org/r/#/c/206172/ [21:39:21] dapatrick: which project are you looking to run tests for? [21:39:36] Just core mediawiki. [21:40:05] those instructions might be out of date in all sorts of fun ways [21:40:17] assuming we upgraded core tests to use mw-selenium 1.x [21:40:19] let me check [21:40:23] :/ [21:41:08] the upside is that running them should be easier now [21:41:22] dapatrick: start here https://doc.wikimedia.org/rubygems/mediawiki-selenium/ [21:43:40] dapatrick: looking at the `environments.yml` file, mw-vagrant-host is the default, so you should be able to get away with just `bundle exec cucumber` under `tests/browser` [21:43:50] (once you have the dependencies installed via `bundle install`) [21:45:28] marxarelli: Swell. Thanks for this. [21:45:45] no problem. let me know if you run into issues [22:42:55] bd808: what are the risks for https://gerrit.wikimedia.org/r/#/c/230233/ ? [22:43:23] crushing statsd [22:43:33] other than that pretty much nothing ;) [22:44:01] ah yeah, just saw your comment [22:44:12] yeah, better leave that for filippo then :P [22:44:30] I was going to look at the puppet classes we have and see if it would be reasonable to provision statsd along side logstash just for this [22:47:27] are you cool with https://gerrit.wikimedia.org/r/#/c/230679/ ? i tested it [22:47:55] yeah. My scap test env is borked :/ [22:48:39] thcipriani and twentyafterfour should really start +2 these things (in a perfect world) [22:49:45] ori: I can test with a cherry-pick in beta [22:49:50] * bd808 does that [22:49:58] woot, thanks [22:52:01] I see CommonSettings.php still doesn't use wfLoadExtensions [22:52:47] TimStarling: I haven't gotten around to converting it, around half of the PHP entry points just call wfLoadExtension() [22:52:59] right [22:53:56] https://tools.wmflabs.org/extreg-wos/ [22:54:06] I see mergeMessageFileList.php already has extension.json support [22:54:27] (everything with bug numbers are Wikimedia-deployed) [22:54:28] yep :) [22:56:16] ori: does https://gerrit.wikimedia.org/r/#/c/226640/ deserve a +1 from you now even though you don't love this as a complete solution? [22:56:31] oh sure, yeah, let me re-review [22:56:35] I will +2 if you +1 (or you could +2 yourself) [22:56:57] I need to deploy ParsoidBatchAPI, that's why I am looking at this [22:57:14] i'll just +2 [22:57:21] <3 [22:57:33] wellllll [22:57:34] actually [22:57:44] 1:1000 is kind of wikimedia-centric, should it be a config var? [22:57:56] i won't block on that, but tgr, something to consider ^ [22:58:07] *nod* it would make sense [22:59:47] it should be, but I was lazy [23:00:01] I will move it if we think we'll keep the sampling feature around [23:01:31] ori: wellllll actually -- https://twitter.com/actually_hn [23:01:48] haha [23:06:15] I don't think I've ever actually added an extension to beta [23:06:40] it's mostly the same, except you use the -labs suffixed files [23:06:54] and then cross your fingers that jenkins deploys it properly [23:07:23] so how does the code get checked out there? does it just checkout everything in mediawiki/extensions.git? [23:08:29] to get it deployed for the current production branch, you'll need to add it as a submodule for the branch [23:09:25] TimStarling: yes, beta cluster clones all of mediawiki/extensions.git when it updates via the jenkins job [23:09:30] TimStarling: yeah, the entire mediawiki/extensions repo is cloned [23:10:18] ori: is that necessary? is there a script I can update which will make it appear next time a release branch is cut? [23:10:57] mediawiki-tools-release/make-wmf-branch [23:11:08] yeah, make-wmf-branch/default.conf in mediawiki/tools/release.git [23:11:10] what legoktm said [23:15:21] I think I actually wrote the original version of that script [23:16:37] heh, it didn't have configuration in json format back then though [23:18:54] I changed that pretty recently (around Lyon) :P [23:19:09] mainly so forrestbot could get the list without reading PHP [23:31:17] ok, I've uploaded 3 relevant changes to gerrit [23:31:52] TimStarling: your mediawiki-config patch isn't using wfLoadExtension? [23:32:23] oh, I figured it wasn't allowed since there were literally zero doing it that way [23:32:37] I can do it though [23:33:45] no, just that I haven't gotten around to doing it. yes please :) [23:38:29] there you go [23:38:42] oh, you gave it +1 already [23:38:53] thanks [23:39:29] :) [23:40:30] I'll merge that now then, and test it? [23:43:06] sounds good :)