Blog: https://addshore.com
Twitter: https://twitter.com/addshore
Meta: https://meta.wikimedia.org/wiki/User:Addshore
Wikitech: https://wikitech.wikimedia.org/wiki/User:Addshore
🦓🐝🐢
Blog: https://addshore.com
Twitter: https://twitter.com/addshore
Meta: https://meta.wikimedia.org/wiki/User:Addshore
Wikitech: https://wikitech.wikimedia.org/wiki/User:Addshore
🦓🐝🐢
Greping code I assume this is coming from https://github.com/wikimedia/mediawiki/blob/REL1_39/includes/page/Article.php#L361
What is the contents of the .env file in /home/lectrician1/.config/mwcli/mwdd/default/?
What is the contents of the .env file in /home/lectrician1/.config/mwcli/mwdd/default/?
Can you run mw -v=2 docker mediawiki create to see what the additional output is please?
Use case(s): There is currently no possibility to display images and other media in a Wikibase.cloud-instance. The only option is to show a link, but not the media.
The integration of the Local Media extension would change that.
The failed jobs DB table should reveal the reason for the failures.
For reasons not clear, we need to limit the amount of jobs per request to MediaWiki to 2 (https://www.mediawiki.org/wiki/Manual:Job_queue).
In T333029#8726985, @hashar wrote:Alternative is to have Gitlab replication to use it is own based after the GitLab repository name instead of the Gerrit one. Eg:
Source GitHub Gerrit mediawiki/tools/cli https://github.com/wikimedia/mediawiki-tools-cli Gitlab releng/cli https://github.com/wikimedia/releng-cli (given that if on GitHub one renames mediawiki-tools-cli to releng-cli, I am pretty sure GitHub will honor the redirect when Gerrit replicates so we are back to point 1). Then for the mirror I don't think we need to keep the Gerrit based name.
In T333029#8726034, @hashar wrote:Note: https://github.com/wikimedia/mediawiki-tools-cli is a mirror of the Gerrit repository https://gerrit.wikimedia.org/r/admin/repos/mediawiki/tools/cli
And it is indeed replicated:
gerrit1001:/var/log/gerrit/replication_log[2023-03-24 05:42:12,197] Replication to git@github.com:wikimedia/mediawiki-tools-cli started... [CONTEXT pushOneId="3ed2eea4" ] [2023-03-24 05:42:12,519] Push to git@github.com:wikimedia/mediawiki-tools-cli references: RemoteRefUpdate{refSpec=refs/heads/main:refs/heads/main, status=NOT_ATTEMPTED, id=(null)..AnyObjectId[e1fd6968eb15285bc159b7176b9aa54b4e4458d1], force=yes, delete=no, ffwd=no} [CONTEXT pushOneId="3ed2eea4" ] [2023-03-24 05:42:13,105] Replication to git@github.com:wikimedia/mediawiki-tools-cli completed in 907ms, 809789ms delay, 7 retries [CONTEXT pushOneId="3ed2eea4" ]
13:get remote references: create git ls-remote: exit status 128, stderr: "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\n@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @\r\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\r\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\r\nIt is also possible that a host key has just been changed.\r\nThe fingerprint for the RSA key sent by the remote host is\nSHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.\r\nPlease contact your system administrator.\r\nAdd correct host key in /tmp/gitaly-ssh-invocation2616940952/known-hosts to get rid of this message.\r\nOffending RSA key in /tmp/gitaly-ssh-invocation2616940952/known-hosts:1\r\n remove with:\r\n ssh-keygen -f \"/tmp/gitaly-ssh-invocation2616940952/known-hosts\" -R \"github.com\"\r\nRSA host key for github.com has changed and you have requested strict checking.\r\nHost key verification failed.\r\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\n".
Looks like it is set up in the gitlab settings for the repo...
0.22.1 is releasing now
Scratch that, I can, just I was on 0.21.0 to start with
Indeed this happens in 0.22.0!
And there is currently no e2e test for this method
I don't appear to be able to reproduce :/
gitlab.wikimedia.org/repos/releng/cli/internal/cmd/docker.NewMwddUpdateCmd.func1(0xc0006b3b00?, {0x1ca89b8?, 0x0?, 0x0?}) /builds/repos/releng/cli/internal/cmd/docker/update.go:20 +0x137
This is...
Ohia all, thanks for all the discussion :)
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Released in v0.22.0
https://gitlab.wikimedia.org/repos/releng/cli/-/releases/v0.22.0
Using an env var would also be "lame" as the env var only relates to the docker sub command, and having --context is quite a nice user experience...
Another option would be storing a default wiki name in the general mwcli config, or in a new mediawiki sub command specific config...
This would allow the persistent pre run of the mediawiki command to set the env var file itself.
Similar to what is done for the MEDIAWIKI_VOLUMES_DOT_COMPOSER variable right now
A tiny issue with being able to implement this right now is that the default flag value for dbname can not be correctly set in the help output, as if --context is used, the env var of the default db name would not be known
https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/384/diffs#68bbf3d56ab35afc40a5844690acde92a7cf4d98_305_308
I wonder if this should be via mwdev docker env set DEFAULT_WIKI <wikiname>
This would mean that things such as mediawiki would know the default wiki (this is a win for running maintenance scripts etc)
But it would also require those containers to be restarted once the env var is set,
So the env command should probably suggest that containers be restarted once env vars are changed...