In T288031#7258018, @Aklapper wrote:

https://bugs.chromium.org/p/gerrit/issues/detail?id=12991

In T285077#7216881, @Lucas_Werkmeister_WMDE wrote:

I just realized the heading on the page is translatable (query-builder-heading message) – should the <title> also be translated? (And if yes, using the same message or a different one?)

In T287588#7243401, @Michael wrote:

in fact, it seems all queries linked on the front page seem to be breaking with 502 Bad Gateway.

😬

Thanks for pointing that out! I look into it - that's not how it is supposed to be

in fact, it seems all queries linked on the front page seem to be breaking with 502 Bad Gateway.

This probably either needs some investigation on how to do this, or maybe a decision on T287588: Figure out if wikibase-registry should move to wbstack or maybe use k8s natively

After deleting the duplicate container, taking /root/wikibase-registry/docker-compose.yml as the source of truth for what container are supposed to run and running sudo docker container prune and sudo docker image prune, we're back to 11% free space:

Apparently, most of the disk usage was concentrated in the docker directory, due to old jobs somehow dangling there. We will look into this more. We will also check for the emails and try to find a solution where this does not happen again.

In T285104#7239822, @Joe wrote:

I think there are two options, depending on the level of security we want to achieve and the urgency of bringing this to production:

1. We just point to the current installation and it should just work(TM). But we'd need to perform a small migration afterwards.
2. We wait for Serviceops to set up an ingress properly, which is next in line for us, and we do a proper separate shellbox deployment for this. It will take more time but will in the end cost less.

This is stalled on T176312: Don’t check format constraint via SPARQL (safely evaluating user-provided regular expressions), which in turn is stalled on T285104: Deploy Shellbox instance (shellbox-constraints) for Wikidata constraint regexes.

Is there an update on this? Anything we (WMDE) can do to help this move forward?

Yeah, it fetching Jessie things is strange indeed. I'll have a look at your suggestions, thank you

In T285761#7221309, @Addshore wrote:

@Michael @Lucas_Werkmeister_WMDE how about we close this / merge it into the checklists on T266703: Deploy query builder to microsites (on top of the wdqs-ui) ?

I created an example repo demonstrating this bug and opened an issue upstream.

In T282086#7198936, @Ladsgroup wrote:

It's a bit hard to test. I can start a job and then make it fail?

We may need https://github.com/underfin/vite-plugin-vue2 and also maybe see https://github.com/vitejs/vite/issues/305 for background discussions.

We forgot about wfGetDB(). I'll be creating a couple more subtasks...

This recently added Setting on GitHub seems relevant here: https://github.blog/changelog/2021-07-01-github-actions-new-settings-for-maintainers/

(I'll be finishing my work on this, tackling the remaining ACs)

In T283040#7197517, @gerritbot wrote:

Change 703192 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/Wikibase@master] Remove subscribing to other aspect for entity usage

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

The eventual production one. We discussed that these headers are likely not to be added in the Query Builder code itself, but in the Apache server configuration, which probably does not live inside the Query Builder Repo. Though adding them to the test-server as well could be a decent test-run.

In T284231#7193283, @Lucas_Werkmeister_WMDE wrote:

I think this might be blocked on MediaWiki’s rdbms library becoming available as a composer package – otherwise, this package won’t be able to stand on its own…

Edit: that would be T158929: Librarize MediaWiki database layer and drop official support for non-MySQL engines.

In T286058#7197850, @Lucas_Werkmeister_WMDE wrote:

In T286058#7197812, @Michael wrote:

In T286058#7194272, @Lucas_Werkmeister_WMDE wrote:

No, wait, docker-registry.wikimedia.org/releng/node12-test-browser:0.0.2 is the image that will be executed by that docker run command inside the script. I don’t know where the script runs. Directly on the Jenkins host?

From the logs, I would interpret the beginning of the prompt [generic-node12-browser-webdriver-docker] $ [...] as meaning that we are inside of some node12 container?

I think this just means that Jenkins is currently running the generic-node12-browser-webdriver-docker job (configured as {name}-node12-browser-webdriver-docker in jjb/job-templates.yaml, which uses the docker-run-with-log-cache-src builder, and that ultimately comes down to the docker-run builder we’ve seen in T286058#7194166. This builder is supposed to run a node12 container, but I don’t think the builder itself runs in that container.

In T286058#7194272, @Lucas_Werkmeister_WMDE wrote:

No, wait, docker-registry.wikimedia.org/releng/node12-test-browser:0.0.2 is the image that will be executed by that docker run command inside the script. I don’t know where the script runs. Directly on the Jenkins host?

In T284227#7195590, @Addshore wrote:

[...]
@Michael how did you set the value?

What do you see when you do mwdd env list? or cat the .env file?

In T285473#7191553, @Addshore wrote:

Hi @Michael
As the current "unstaller" on camp for this week, could I ask for details to be added regarding why this task is in stalled / waiting?
What is it blocked on / waiting for?

In T277862#7191548, @Addshore wrote:

Still waiting on T274579: Upgrade WebdriverIO to the latest version 7 for all repositories
Thought we could bring this upgrade into our backlog to see if it helps.
Thoughts @Michael ?

In T283040#7189663, @Ladsgroup wrote:

in particular, most of the documentation for the "Other" aspect seems out of date as it seems to actually include Alias-usage and existence checks, but not Description usage

Description usage is not "Other" usage AFAIK. Am I missing something very obvious?

It seems it makes more sense to work on T285472: Remove entityNamespaces settings first and on this one last.

Maybe, this shouldn't have gone into "Verification" just yet, because the other ACs are genuinely still open, given that the meaning of the "Other" aspect has changed at some point in the past and all documentation except the API docs is (now) incorrect.

In T283911#7169942, @Lucas_Werkmeister_WMDE wrote:

I’m not sure about the first-time contributors things, but as I understand it, the main problem is that pull requests from forks won’t have access to secrets, so they’ll be missing various API keys.

TL;DR: We should take some time to consider alternatives to Selenium+Webdriver.IO before rewriting a large number of Ruby tests.

First version of the script: P16729