If there are open Addbot patches

Apparently the GitHub action deploying the new version had a strange error (both in the “staging” and “production” runs):

Very cool, thank you!

Oh, I didn’t realize that the branch-deploy npm script runs as part of CI test builds. You should be able to see the language selector here, then: https://901247--clicky-sparqly.netlify.app/

We intentionally haven’t deployed it to https://query.wikidata.org/querybuilder/ yet. I guess the easiest way to verify it would be via Netlify, similar to T324653, but I don’t know how to publish it there.

In T329167#8687793, @gerritbot wrote:

Change 897906 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Move sitelinks collapse toggle into heading using placeholder

https://gerrit.wikimedia.org/r/897906

In T332702#8717933, @gerritbot wrote:

Change 901555 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] WIP: Ensure content languages are sorted by language code

https://gerrit.wikimedia.org/r/901555

The basic query builder is merged; still missing are keyboard navigation, possibly further mobile / RTL changes, and also probably saving the selected language in local storage (or a cookie or whatever).

This turned out to happen naturally as part of T328148: LangSelector added to Query Builder; Add autonym in Language Selector Button includes a test for it.

Hm, if this is still happening according to T332540 after the above change was merged, then that might not have been enough to fix the issue :(

We currently use Husky v1, which installs itself by generating a script for every possible Git hook in .git/hooks/, silently overwriting any already existing hook there. The latest version is v8, which works differently: it changes the core.hooksPath Git config to point to .husky (see this blog post for details), which turns the hook in .git/hooks/commit-msg into dead code.

Mossi is fixed (good), but Tswana is still open AFAICT.

Regex Format constraints currently show only the regex.

Depending on how we implement a no-verbose-printing-by-default setup, you could set something like putenv( 'MW_PHPUNIT_VERBOSE="1"' ) somewhere in Wikibase's setup code when debugging a task, to swtich back on the dot printing. Would that be acceptable?

I tried updating the ->update() call in SqlIdGenerator, but ran into problems (T332329). I think we can consider this task done in the meantime; git grep -Fe '->select' doesn’t find any remaining unconverted uses.

It turns out that SelectQueryBuilder also doesn’t support ->where( $dbr::ALL_ROWS ), though it’s not as much of a problem there because you can just omit the ->where() call.

Apparently these test failures are due to the test changes? When I [revert them](I3a2b3655cecd12fa91d2c58c04479e1e4fd2bb91), check php passes again. o_O

In T331621#8680411, @Lucas_Werkmeister_WMDE wrote:

I agree that scrolling through the progress indicators is annoying when looking for test results, but I also find it quite helpful while the tests are still running.

Agreed. It’s also useful when tracking down a particular test failure (perhaps one that only affects CI), to see if CI already reached that test (whether it passed, failed, errored, or totally crashed) or not yet.

I’m pretty confused by the Gerrit discussion on that old change, but if I understand correctly, I guess we can just remove the transaction around the big loop in run()? Having beginAtomic() / endAtomic() around the entire contents of run() doesn’t seem very useful indeed.

FWIW, I tried running our browser test suite against Wikidata.

Okay, looks like it’s not a general problem after all. Must be something wrong with my change, though I have no idea what…

No error in the php81 gate-and-submit for this tiny change so far either…

Okay, both the test and php pipelines succeeded there now. Untagging shared build failure while it’s unclear that it really affects more than just the one change. Let’s wait for a proper gate-and-submit on another Wikibase change and see how that goes.

Hmm, it doesn’t seem to happen in the check php build for the above change so far. Perhaps there’s some unexpected issue with the Gerrit change where the gate-and-submit errors happened?

(Looks like https://gerrit.wikimedia.org/r/c/labs/codesearch/+/898060 is the relevant Gerrit change.)

I guess so? Looks fine here as well now.

It should behave the same way that shift-click or control-click normally behaves on buttons, opening the new lexeme in a new tab or new background tab.

So the first of the above changes, Make DateFormatParser accept more Asian/Chinese date formats, enables Wikibase to parse dates like “2023年3月12日” in Japanese as 2023-03-12. That change seems unproblematic and is good to go, I think.

(FWIW, the same YubiKey now does require touch as expected – ever since I got a new work laptop, IIRC. Slightly weird but not the end of the world.)

In T330624#8688872, @gerritbot wrote:

Change 897956 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/EntitySchema@master] Enforce trailing commas in multi-line arrays

https://gerrit.wikimedia.org/r/897956

Should the current user interface language be part of the shareable link or not?

I believe this is done now, all production environments use docker-registry.discovery.wmnet/wikimedia/wikibase-termbox:2023-03-06-101138-production which is based on Node 16.

I agree that scrolling through the progress indicators is annoying when looking for test results, but I also find it quite helpful while the tests are still running.

selenium-daily-beta-WikibaseLexeme (various error messages)

Can I take one step back and ask what are you using this max lag measure for, and how?

Just leaving a pointer here that for Wikidata production we solved essentially the same issue in T301461. (TL;DR: we also went for Cache-Control: no-cache. Keep in mind that applies not only to index.html but also to embed.html!)

Tagging this as an incident follow-up – while the maxlag was high, edits slowed down drastically (which is the correct response to high maxlag ^^) – see Grafana:

double check if any commits were missed while it was broken and if so, push them to the respective places

Did we do this?

It’s finally working again.

Apparently there’s a v1.21.3 now (Dependabot change), we can check if that still has the regression or not.

It looks like the Jest 28 upgrade only changed the meaning of the diagnostics: false flag in jest.config.js to also hide all the TS errors. If that flag is removed (which we ultimately want), then the errors are still there 😩

Pulling into the sprint to reflect that we worked on it; post-hoc estimated as “no smaller than 5 and no bigger than 8”.

Also https://github.com/wmde/git-monorepo-splice-docker-action/pull/2.

@Michael managed to fix T329553 (unblocking this task), and the Jest 28 upgrade indeed got rid of all the TS2307 / “cannot find module” errors. (There are plenty of new errors from sass about the / syntax being deprecated, but that’s a separate issue.)

Proposed fix: https://github.com/wmde/Time/pull/167

FWIW, @toan is indeed no longer working at WMDE. I’ll see if I can find someone on our side who knows more about the offboarding process.

CC @Krinkle and @Ladsgroup from build: Change diffConfig to use git-stash instead of git-add yesterday.

In T330752#8660288, @Stashbot wrote:

Mentioned in SAL (#wikimedia-releng) [2023-03-02T12:39:16Z] <Luca> wikidata/query-builder/deploy.git: changed HEAD from master to production # T330752

In T327511#8656355, @HasanAkgun_WMDE wrote:

We can only use overflow-wrap: anywhere; on item links and it solves wrapping problem without breaking table layout.

Code:

a.item-link {
  overflow-wrap: anywhere;
}

Screenshots:

While we should of course handle this without crashing, it’s also clearly not a valid request: the code that is making these API requests is also broken. From GitHub search, wd-recon-lang seems to come from OpenRefine, especially the preview-renderer:

Can be reproduced locally with something like { "lang": "core-recon/wd-recon-lang" } in the options parameter, e.g.: