[03:04:11] (PS1) AndyRussG: QUnit: fix PHP error by setting $wgCentralDBname [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) [03:04:50] (CR) jenkins-bot: [V: -1] QUnit: fix PHP error by setting $wgCentralDBname [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) (owner: AndyRussG) [17:08:04] hey awight are you out today or wfh? [17:08:10] (also be healthy!) [17:08:27] atgo: sorry, WFH [17:08:35] I should have specified :) [17:09:07] Which is effectively like I'm out so far, cos there is a completely insane kid climbing everywhere. [17:09:29] Anyway, do you have thoughts about things I should be paying attention to? [17:09:39] * awight glances nervously at calendar [17:10:17] The check-in! Will be there. [17:29:23] (CR) AndyRussG: [C: -1] "Wrong approach, working on something different. The errors in the PHP tests are a separate problem: those tests shouldn't care about the v" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) (owner: AndyRussG) [17:31:09] it's all good! just making sure we shouldn't move the MG checkin to another day [17:31:13] :) [17:32:16] awight: looks like you made some CI progress over the weekend eh? [17:32:27] o_o` [17:32:38] Who's leaking :p [17:33:05] Yeah quite a bit. We're actually ready to go, just a little CR and some optional extra credit things that can be spread out in TODO-land [17:40:09] * awight leaps out of shadows [17:41:20] ejegg: Hi! Take your time, but jfyi, this is the PCR stuff I'm most interested in deploying first, cos I currently have a special-case line in the CI job, to checkout an unreviewed patch, which needs to go away... https://gerrit.wikimedia.org/r/#/q/status:open+project:wikimedia/fundraising/civicrm-buildkit,n,z [17:41:48] hi awight [17:42:09] been poking around it a bit, should have some feedback soon! [17:42:28] cool, thanks! [17:44:53] ejegg: I'm excited to do the DI deployment :) Lmk if you want to be around to watch the pretty flames [17:46:13] heh, most definitely [17:46:38] awight: there are still two logging patches that need a re-review after I had to rebase them manually [17:48:51] ah ok lemme see. [17:48:56] https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/DonationInterface+branch:master+topic:newlogging,n,z [17:49:39] very little change from what you +2ed originally, just a couple places where they touched the 'delete unused code' patches [18:01:09] (CR) Awight: [C: 2] Use PSR logging in gateway adapters [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/193272 (https://phabricator.wikimedia.org/T86266) (owner: Ejegg) [18:01:40] (Merged) jenkins-bot: Use PSR logging in gateway adapters [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/193272 (https://phabricator.wikimedia.org/T86266) (owner: Ejegg) [18:05:06] (CR) Ejegg: [C: 2 V: 2] pushd to less crazy directory before running drush [wikimedia/fundraising/civicrm-buildkit] - https://gerrit.wikimedia.org/r/195010 (https://phabricator.wikimedia.org/T78100) (owner: Awight) [18:05:19] (CR) Ejegg: [C: 2 V: 2] Ignore vendor [wikimedia/fundraising/civicrm-buildkit] - https://gerrit.wikimedia.org/r/195011 (https://phabricator.wikimedia.org/T78100) (owner: Awight) [18:05:49] blargh! conflict [18:05:57] (CR) Awight: [C: 2] Use PSR logging in GatewayPage classes (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/193280 (https://phabricator.wikimedia.org/T86266) (owner: Ejegg) [18:05:59] (CR) jenkins-bot: [V: -1] Use PSR logging in GatewayPage classes [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/193280 (https://phabricator.wikimedia.org/T86266) (owner: Ejegg) [18:06:04] ah, phooey [18:06:04] rebasing.. [18:07:39] (CR) Ejegg: [C: 2 V: 2] Don't install SimpleTest modules [wikimedia/fundraising/civicrm-buildkit] - https://gerrit.wikimedia.org/r/195054 (owner: Awight) [18:08:05] (PS5) Awight: Use PSR logging in GatewayPage classes [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/193280 (https://phabricator.wikimedia.org/T86266) (owner: Ejegg) [18:08:26] ty [18:09:02] (CR) Awight: [C: 2] Use PSR logging in GatewayPage classes [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/193280 (https://phabricator.wikimedia.org/T86266) (owner: Ejegg) [18:09:26] (Merged) jenkins-bot: Use PSR logging in GatewayPage classes [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/193280 (https://phabricator.wikimedia.org/T86266) (owner: Ejegg) [18:10:43] (CR) Ejegg: [C: 2 V: 2] Mock VCS revsion stamp [wikimedia/fundraising/civicrm-buildkit] - https://gerrit.wikimedia.org/r/195055 (owner: Awight) [18:13:50] (CR) Ejegg: [C: 2 V: 2] Don't include civicrm_webtest [wikimedia/fundraising/civicrm-buildkit] - https://gerrit.wikimedia.org/r/195058 (owner: Awight) [18:14:09] (CR) Ejegg: [C: 2 V: 2] We don't use the devel module in tests [wikimedia/fundraising/civicrm-buildkit] - https://gerrit.wikimedia.org/r/195065 (owner: Awight) [18:15:12] * awight looks around [18:15:18] That was it! Thanks, ejegg! [18:15:50] sure thing! Looks like you found a bunch of other little stuff while you were working on the CI... [18:16:25] Nothing compared to what we'll find when we migrate the remaining Simpletest modules to PHPUnit :) [18:16:39] ooh, that'll be fun [18:16:48] (CR) Ejegg: [C: 2] Fix watchdog() call params [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195059 (owner: Awight) [18:17:04] CR'ing the CRM stuff is not a huge rush, but when that's done, we can set the job to voting. [18:17:19] nice! [18:18:19] (CR) Ejegg: [C: 2] "Ah, this looks fundamental! :P" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/194998 (https://phabricator.wikimedia.org/T78100) (owner: Awight) [18:26:35] (CR) Ejegg: [C: 2] Correct mysql client machine name [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195002 (https://phabricator.wikimedia.org/T86374) (owner: Awight) [18:31:18] (PS4) Awight: WIP null patch for testing [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195071 [18:31:56] * awight is glued to https://integration.wikimedia.org/ci/job/wikimedia-fundraising-civicrm/12/console [18:32:34] heh, just looking at the timestamp fix [18:32:35] * awight shoots some holes in the ceiling in happiness [18:33:31] (Abandoned) Awight: WIP null patch for testing [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195071 (owner: Awight) [18:34:12] Mostly, I was testing the latest jjb definition, which in theory should work for changes on the drupal, civicrm, and vendor repos as well. [18:34:35] oh, nice [18:35:05] ejegg: fyi, I think I found where the CI cabal lurks, #wikimedia-releng [18:35:48] hmm, that's a fair-sized cabal! [18:36:16] Mostly rubberneckers :D [18:37:11] Hrm, I wonder why the exchange rates hack no sirve [18:38:31] which ones? [18:38:46] Perhaps it was a rebase issue... [18:38:50] oh, https://gerrit.wikimedia.org/r/#/c/195052/ ? [18:39:01] Yep [18:39:13] I'll try bumping the head patch. [18:40:05] (PS1) Awight: WIP null test patch [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195329 [18:54:41] OK, all passes and skips. [18:55:08] (Abandoned) Awight: WIP null test patch [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195329 (owner: Awight) [19:15:11] (CR) Ejegg: [C: 2] Handle dates more carefully in recurring messages [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195050 (owner: Awight) [19:17:57] (CR) Ejegg: [C: 2] split -> explode [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195051 (owner: Awight) [19:39:04] (PS4) Awight: Remove HTML Entities from Civi Contacts Table [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/110047 (owner: Mwalker) [19:52:45] (PS2) AndyRussG: QUnit: avoid PHP error by using fallback API URL for banner choices [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) [19:54:18] (PS1) Awight: Move remaining contrib modules into new home [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195347 [19:54:40] (PS2) Awight: Move remaining contrib modules into new home [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195347 [19:58:47] (CR) AndyRussG: "So now the QUnit job only emits a warning. I wonder if that'll help qunit karma?" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) (owner: AndyRussG) [20:00:23] (CR) AndyRussG: "Re: PHPUnit independence of CN config: https://phabricator.wikimedia.org/T92000" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) (owner: AndyRussG) [20:02:16] (CR) Ejegg: [C: 2] Mock exchange rates during testing [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195052 (owner: Awight) [20:04:41] (PS1) Awight: Add JSHint configuration [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195355 [20:04:58] awight you standing up? [20:12:59] awight: you sound so sick! [20:14:37] atgo: Feel free to borrow my keyboard if u want to try out this sinus thing :p [20:14:58] ah thanks! you're so generous :P [20:15:41] It's annoying being sick, but my perspective has definitely change on this stuff--seeing kid w/ flu is probably 10x worse than actually having it! [20:19:25] ejegg: This test flapping is pretty creepy... https://integration.wikimedia.org/ci/job/wikimedia-fundraising-civicrm/18/consoleFull [20:20:13] I don't see any reason the exchange rates thing wouldn't stick. Maybe I'm overlooking commit dependency rebase thing? [20:25:39] odd indeed - i don't see any dependency issues [20:26:01] I'll squint at the code some more... but that really makes no sense at all. [20:26:22] It's just a global var, no way it can be leaking across test runs. [20:27:18] (CR) Ejegg: [C: 2] Mark test as skipped directly [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195053 (owner: Awight) [20:27:25] There is one fragile piece of that mockery, actually, that the timestamps have to match exactly for an exchange rate to be pulled from the cache. [20:27:38] Luckily, that's an integer... [20:27:59] in real usage, we're rounding that down to the day or something, right? [20:29:07] hey awight ejegg can i use this for GC, too? https://collab.wikimedia.org/wiki/Fundraising/Engineering/Fun_SQL_Queries#Worldpay_fraud_filter_rejection_breakdown_on_rejected_payments_for_the_last_24_hours [20:29:08] sadly, no. [20:29:22] atgo: yep, that's the place! [20:29:39] sweet. so i'm going to edit the wiki to not say anything about how that's for worldpay? [20:29:58] would that work? [20:30:06] ejegg: Yeah, the cache seems pretty much useless for that reason, it only helps when running exactly the same message through. [20:30:18] atgo: Sorry, I jumped the gun on your question. Lemme look more closely. [20:30:26] ok thanks [20:30:34] I thought you were saying, was that the right place to add more queries :) [20:31:06] looks pretty good, just swapping our the pi.gateway filter in the where clause [20:31:34] yeah that's what i did [20:31:35] thanks :) [20:32:17] +1 [20:32:51] Exactly fraud breakdown stuff might vary by gateway, but the query here is just listing what happened, which is fine. [20:33:03] (CR) Ejegg: "recheck" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195347 (owner: Awight) [20:33:08] O_o /me examines grammarly [20:33:16] ejegg: good thinking [20:33:54] Flapping would be... a problem that would result in the loss of voting rights :p [20:33:56] if it passes i'll be confused [20:35:44] MEanwhile, Zuul is getting defribbulated [20:40:34] i think.. i'm crazy. [20:40:47] or something is weird with this AF stuff [20:40:48] hrm? [20:41:56] i need to do more sql stuff to feel at all confident [20:42:16] but i just emailed, if someone has a chance to tell me how i'm wrong sometime, that would be cool. no rush :) [20:59:26] (PS1) Awight: Add "composer test" entry point [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/195375 [20:59:53] ejegg: you might like ^, apparently that's the new thing. [21:00:36] composer npm grunt karma test? [21:00:58] sweet [21:03:52] banana gateways? [21:04:34] oh, testing the i18n JSON [21:05:52] O_o wat [21:15:10] Wikimedia-Fundraising, Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips: Make Civi Reminders work in Staging - https://phabricator.wikimedia.org/T86345#1101536 (atgo) [21:35:25] Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog: Document CiviCRM custom imports - https://phabricator.wikimedia.org/T92025#1101738 (awight) NEW [21:40:22] CaitVirtue: about that loyal donor smart group--I don't think the smart group part will be easy, but it looks like there's already a "Top Donor" report. [21:40:30] Trying to figure out where that appears in the UI... [21:42:36] awight, CaitVirtue: you can get to that via Reports-> Create Reports from Templates [21:42:53] ok thanks, Rosie and I will check it out [21:43:54] CaitVirtue: https://civicrm.wikimedia.org/civicrm/report/instance/23?reset=1 [21:44:37] That has total amount and donation count... [22:28:50] awight: Do we log if a donation amount was selected from one of the fixed options? [22:56:58] hey awight ejegg we don't need to take down campaigns for the DI deploy on Thur, right? [22:57:10] like... people will just end up in queue? [23:00:46] ejegg|away: Do you happen to know the current magic knock to do a composer update in DI? [23:02:02] ejegg|away: oops. I mean in crm/ -- it's glitching out on wikimedia/donation-interface whether I remove it, or checkout from the vendor/ repo [23:06:30] Hehe, looks like this is the ticket, for lack of a better idea: rm -rf vendor/ [23:07:17] yep, that's the easiest way i've found! [23:07:25] argh :) [23:07:29] We gotta do something... [23:07:58] So, it's just a compliation step. That's why it's so distaseful and unsafe to check in the output along with the source change... [23:08:09] yeah [23:08:25] The only reason to include vendor/ is for production... [23:08:40] so err, maybe we should get rid of the submodule [23:08:41] right, since we don't want to d/l stuff as part of deployment [23:08:59] well, we don't need or want this cruft in dev or testing environments. [23:09:08] argh, I cannot make the last jump [23:09:39] It really comes down to having a cache of the packages we need to install [23:09:46] yeah [23:10:15] and... having some reasonable assurance that the contents are being tracked, not changing randomly during deployment [23:10:42] need to either tag or package up our own stuff to pin it [23:11:08] I wonder if it would be good enuf to have the deployment script run the "composer install", based on composer.lock, but then allow for manual review of the diff --stat [23:11:44] ooh, that would be a lot to review during deployment [23:11:58] yah, but only when the composer.lock had changed... [23:12:06] hmm, right [23:12:19] and it wouldn't need to be a line-level review [23:12:32] yeah, just making sure the same files are there as you expect [23:12:35] as long as we have a VCS of what we've been deploying? [23:12:38] yeah [23:13:31] honestly doesn't sound a lot better than checking in vendor/ [23:14:10] True [23:14:45] But I think there's something here... we unlink vendor/ from the parent repo. So dealing with vendor/ in git is only necessary when you're actually making a package change. [23:15:14] mmm. How are they doing this with mw-core? [23:15:25] ah, good question! [23:15:26] something like current harebrained scheme? [23:16:40] well, it's a submodule [23:17:04] ...or is it? [23:17:19] Doesn't seem to be. [23:17:19] oh, vendor/ is in core's .gitignore now [23:17:36] the readme https://github.com/wikimedia/mediawiki-vendor says it's only for the prod situation [23:17:55] ... I'm not sure what the deal is with "testing", I think they might be serious about that. [23:17:55] huh, so is composer.json and composer.lock [23:18:04] ignored?? [23:18:22] yeah, that can't be right [23:18:27] I'm mad as hell & not gonna take it any longer! [23:18:57] Well, that I have to disagree with, unless there's some really sneaky way to define the dependencies in a .local. file [23:19:39] lol, phpcs errors so far on crm/, EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEWWEEWEEE [23:19:54] heheh [23:20:17] really raising the alarm [23:20:35] excitement for the whole family [23:21:58] huh: https://gerrit.wikimedia.org/r/#/c/182323/ [23:22:27] cos composer alone wasn't complicated enough? [23:23:46] * awight slams my locker a bit [23:24:14] oic, .local. is for extensions you've got installed via composer. [23:24:21] but. oh [23:24:25] still seems odd to ignore the main file [23:25:51] I don't understand why I'm sitting around calling "composer install" on new MW checkouts, in this case. There's something we don't know :) [23:30:59] ejegg: all the nighmares came today :) https://github.com/wikimedia/mediawiki/blob/master/composer.json [23:31:51] oh, what are those hooks? [23:32:36] \o/ [23:33:14] hmm, pre-file-download "allows you to manipulate the RemoteFilesystem object prior to downloading files based on the URL to be downloaded" [23:33:20] " [23:33:20] A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details. [23:33:23] ohwow [23:33:26] why... [23:37:26] (PS1) Awight: WIP Add "composer test" entry point [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195485 [23:39:27] (CR) Awight: "recheck" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195347 (owner: Awight) [23:41:33] ejegg: Anyway, I kind of like detaching the vendor submodule only for prod. Lmk if you think of reasons that would be a bad idea. [23:43:03] awight: then checking it out and running composer to verify the contents are as expected? [23:43:30] har [23:43:32] where would we indicate the desired vendor revision? [23:43:49] Good question [23:44:03] ...or just use a deploy branch? [23:44:05] well, there's the version hints in composer.json [23:44:24] but I guess we ignore the .lock file? [23:45:11] huh, idk if we're thinking about the same issue. [23:45:28] oh, I see whatchu mean now. [23:45:32] So during deployment, we would check out a specific revision of the vendor repo, right? [23:45:51] That is an issue. cos of rollbacks. [23:56:22] Well. Are you suggesting we have vendor/ be a submodule, only in the deployment branch? Cos I don't see a better way, at this point. [23:56:47] yeah, i can't think of anything better either [23:57:10] At least it will keep up from ever reusing the same dir to develop and deploy :)