[08:53:10] Hi! 👋 I'm in a group of university students that are trying to build¹23 [08:53:50] … build a game with wikidata. We hit a 403 error because our request library didn't set a user agent [08:55:19] Unfortunately we didn't get the response telling us the cause but had to research that, which cost some time. I think that might be a bug? https://gerrit.wikimedia.org/r/#/c/wikidata/query/rdf/+/516834/5/blazegraph/src/main/java/org/wikidata/query/rdf/blazegraph/filters/RealAgentFilter.java seems to set a meaningful request body. The one we got was the standard nginx 403 body. [09:19:51] Hi! There were a lot of abused of query.wikidata.org in the last few days so new limits where set: https://lists.wikimedia.org/pipermail/wikidata/2019-June/013185.html [09:24:23] I see. From our understanding there should be a response code 429 first, is that correct? Because we didn't see that. Also, is it expected to just get the standard nginx 403 response body? [09:25:04] Probably not indeed [09:25:47] You could report the problem on Phabricator: https://phabricator.wikimedia.org [09:25:56] With the tag "Wikidata Query Service" [10:39:59] Cool, will do [15:05:38] hi, does the Wikibase extension have a code coverage report somewhere? [15:07:06] kostajh: no [15:07:37] kostajh: Wikibase is not moved to extension.json fully yet, and this has been blocking the code coverage report [15:08:16] leszek_wmde: ah, OK. [15:08:20] kostajh: this could be possible worked around, but last time this was discussed (early 2018/late 2017) it was said that instead of workarounds, Wikibase should rather stick to general practices [15:08:29] which admitedly, we haven't done yet [15:08:34] leszek_wmde: for context: https://www.mediawiki.org/wiki/Topic:V1v7drxacny6l9fq [15:09:29] kostajh: oh, I was suspecting this is why you ask. sad to see that we fail on the coverage part, and it breaks things further down too [15:10:07] leszek_wmde: yeah :( my initial idea is to modify integration/config to allow the sonar-scanner to analyze the code anyway, without the code coverage report. [15:10:59] kostajh: if that would work, and wouldn't be too much hassle in the sonar config, then it sounds good [15:11:19] kostajh: but we wouldn't press for ruining the whole sonar config just for a single exception [15:53:18] leszek_wmde: is Michael Große on IRC? [15:54:20] kostajh: Michael_WMDE, but not in this channel currently it seems [16:00:43] kostajh, sorry for not being in this channel, it wasn't in my autojoin list (fixed now) [16:01:01] * Michael_WMDE is reading the log [16:04:35] Michael_WMDE: no worries :) [16:04:41] I just replied to you on the mediawiki.org thread too [16:09:09] thanks for the context [16:11:45] Doing the analyses even if we fail to generate coverage sounds like a sensible idea. Though it would be nice to have coverage for Wikibase too. [16:13:46] leszek_wmde mentioned that not having fully migrated to extension.json is currently blocking the coverage report. Would looking into finishing that migration improve the situation or is this rather unreleated? [16:16:10] I'm not sure, I don't think that would be the problem [16:16:35] https://gerrit.wikimedia.org/g/integration/config/+/refs/changes/81/517681/1/dockerfiles/quibble-coverage/mwext-phpunit-coverage.sh#37 this command [16:17:09] ah, I see [16:17:43] instead of "$MW_INSTALL_PATH/extensions/$EXT_NAME/tests/phpunit", I think we need to do a `find` command that searches for directories called `tests/phpunit` within $MW_INSTALL_PATH/extensions, and then all of those would be passed as arguments to the `phpunit` entrypoint [16:18:14] the default would be to pass a single directory (extensions/$EXT_NAME/tests/phpunit) but for Wikibase we'd pass (extensions/$EXT_NAME/client/tests/phpunit extension/$EXT_NAME/repo/tests/phpunit etc etc) [16:19:36] mh, sounds like it would work, but not really that nice :/ [16:20:29] I'll try to think of something, but I'll have to run for now. See you tomorrow 👋