https://openstack-browser.toolforge.org/project/language is the Cloud VPS project that owns the named https://translate.wmcloud.org/ proxy.

In T351253#9332838, @bd808 wrote:

Maybe a wikitech-l post requesting feedback from folks who really care here?

In T311466#9365479, @Hawkeye7 wrote:

As you say, the biggest obstacle is that there is no dotnet buildpack available.

I don't know if any work has been done on this.

In T311466#9364202, @bd808 wrote:

This reads to me like splitting your "mono/Liftwing/" directory into a dedicated git repo would make the Toolforge supported system work for this part of your project. You can use https://toolsadmin.wikimedia.org/tools/id/milhistbot/repos/create to create as many distinct git repos for your milhistbot tool as are needed.

In T311466#9353995, @Hawkeye7 wrote:

I have multiple C# projects in the one git repository. It was never intended to be built in this manner.

Marking as stalled until scholarship window closes on 2024-01-05. I will set a local calendar reminder to revisit this task then.

Registration and Scholarship window open:

• https://wikitech.wikimedia.org/w/index.php?title=MediaWiki:Sitenotice&oldid=2130520
• https://www.mediawiki.org/w/index.php?title=MediaWiki:Sitenotice&oldid=6217547

The credentials in the /data/project/mbh/replica.my.cnf file seem to be working as expected:

$ sudo become mbh
$ ls -lh replica.my.cnf
-r-------- 1 tools.mbh tools.mbh 51 Oct  2  2014 replica.my.cnf
$ grep user replica.my.cnf
user='s52321'
$ $ sql srwiki
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Copied from https://commons.wikimedia.org/wiki/File:Wikimedia_hackathon_mark_logo.svg

The gerrit repo and phabricator board should probably be archived as well as marking the various wiki pages as historic too.

Initial announce posted:

• https://wikitech.wikimedia.org/w/index.php?title=MediaWiki:Sitenotice&oldid=2129372
• https://www.mediawiki.org/w/index.php?title=MediaWiki:Sitenotice&oldid=6209617

https://wikitech.wikimedia.org/wiki/Help:Toolforge/Build_Service#Installing_Apt_packages should unblock moving this webservice to Kubernetes.

In T351764#9351145, @Jdlrobson wrote:

maybe create a generic place for this sort of thing in future?

I think a new vhost is a bad idea. There are already a large number of separate generated document collections on doc.wikimedia.org. Just move the thing you want to preserve to a new directory. https://doc.wikimedia.org/mediawiki-core-js-legacy/ or whatever.

@Maryann-Onyinye Check your work email for your initial account information. Unfortunately I cannot remember what sender address account emails from https://techblog.wikimedia.org use.

Quite a bit of work towards making things more configurable happened in the 2.0.0 release cycle as a side effect of making it easier to vary rules across Gerrit, GitHub, and GitLab repos (rICMVf9bfb67cf64b: Refactor into rules based system). I'm not sure however that there is much value in making commit-message-validator. The project is purpose built for Wikimedia commit message rules and was never really intended to be a general purpose commit message linter.

On-wiki docs have now been updated: https://www.mediawiki.org/w/index.php?title=Commit-message-validator&diff=prev&oldid=6207296

@Punith.nyk Thank you for this bug report. It would be helpful if you described the issue using words rather than the attached mp4 screen recording. What screen were you on? What were you trying to accomplish? What unexpected behavior did you find? https://www.mediawiki.org/wiki/How_to_report_a_bug has some additional advice on creating actionable bug reports.

Let's see how this goes:

$ toolforge jobs show fix-double-redirects
+-------------+-----------------------------------------------------+
| Job name:   | fix-double-redirects                                |
+-------------+-----------------------------------------------------+
| Command:    | pwb -family:officewiki redirect both -moves -always |
+-------------+-----------------------------------------------------+
| Job type:   | schedule: @weekly                                   |
+-------------+-----------------------------------------------------+
| Image:      | tool-officewikibot/tool-officewikibot:latest        |
+-------------+-----------------------------------------------------+
| File log:   | no                                                  |
+-------------+-----------------------------------------------------+
| Output log: |                                                     |
+-------------+-----------------------------------------------------+
| Error log:  |                                                     |
+-------------+-----------------------------------------------------+
| Emails:     | all                                                 |
+-------------+-----------------------------------------------------+
| Resources:  | default                                             |
+-------------+-----------------------------------------------------+
| Mounts:     | none                                                |
+-------------+-----------------------------------------------------+
| Retry:      | no                                                  |
+-------------+-----------------------------------------------------+
| Status:     | Waiting for scheduled time                          |
+-------------+-----------------------------------------------------+
| Hints:      | No pods were created for this job.                  |
+-------------+-----------------------------------------------------+

Just a note that this warning is still happening:

Logging in to officewiki:officewiki as Officewikibot@toolforge
WARNING: API warning (main): Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes. Use [[Special:ApiFeatureUsage]] to see usage of deprecated features by your application.
WARNING: API warning (login): Fetching a token via "action=login" is deprecated. Use "action=query&meta=tokens&type=login" instead.
ERROR: Received incorrect login token. Forcing re-login.

Runtime context:

$ webservice buildservice shell -- pwb --version
Pywikibot: [https] toolforge-repos-officewikibot-pywikibot (998aaa8, g1, 2023/11/17, 14:56:35, OUTDATED)
Release version: 8.5.1
setuptools version: 63.4.3
mwparserfromhell version: 0.6.5
wikitextparser version: n/a
requests version: 2.31.0
  cacerts: /app/.heroku/python/lib/python3.9/site-packages/certifi/cacert.pem
    certificate test: ok
Python: 3.9.18 (main, Aug 24 2023, 22:36:08)
[GCC 11.4.0]
PYWIKIBOT_DIR: Not set
PYWIKIBOT_DIR_PWB: /workspace/pywikibot/scripts
PYWIKIBOT_NO_USER_CONFIG: Not set
Config base dir: /workspace
Usernames for family 'officewiki':
        *: Officewikibot

Interactive debugging of things in the buildpack created image can be done using webservice shell. This can be made a bit easier by first setting up a $HOME/service.template for the tool:

backend: kubernetes
type: buildservice
mount: none

With that template in place a script can be run from the cli by doing something like webservice buildservice shell -- pwb -family:officewiki -lang:en redirect both -moves -always. Just use webservice buildservice shell to get an interactive shell inside the container. (This is all normal Toolforge Kubernetes stuff, but possibly not obvious to everyone including my future self.)

Work in progress at https://gitlab.wikimedia.org/toolforge-repos/officewikibot-pywikibot/-/tree/work/bd808/botpassword

@RhinosF1 changed the task status from Stalled to Open.

In T347402#9333908, @Slst2020 wrote:

It is painfully slow though, which is surprising considering that it's just a bare-bones app with some basic CRUD and a sqlite database. Haven't investigated why yet.

There is currently no community or Wikimedia Foundation requirement for separating paid and volunteer contributions to Wikimedia's technical projects. All technical contributors are equally bound by the https://www.mediawiki.org/wiki/Code_of_Conduct and the license terms of the codebases they contribute to.

In T347557#9231642, @nskaggs wrote:

We need a bureaucrat to grant permissions: https://wikitech.wikimedia.org/wiki/Special:ListUsers/bureaucrat

In T347557#9335787, @bd808 wrote:

We should probably just import some nicer 'protectedpagetext' message overrides from meta or mw.o. The default message shipped with MediaWiki is "This page has been protected to prevent editing or other actions." which is true, but not super helpful to folks who don't know what it means. I'll take a shot at setting something better up.

In T347557#9235094, @fnegri wrote:

Thanks, then maybe the note in the page could be "This page is protected, if you need to edit it please contact an admin".

editprotected is technically the right that is needed to edit pages marked visually as "Allow only administrators". On wikitech most folks with this right get it from membership in the content administrators user group. That group has almost the same rights as administrators (sysop) group. The main difference is that content admins do not have the editinterface right that lets you edit things in the MediaWiki namespace which is used for customizing UI messages and global css & javascript.

https://wikitech.wikimedia.org/w/index.php?title=Special:Log&logid=964019

+1 from me for creating the project

gerrit-stats involves a clone of all WMF repos from Gerrit, which comes to 34G. Spitballing, it would probably be helpful to have 80-100G of storage available here.

The default cinder quota for a project is 80Gb. Does that sound like enough space to get started or would you want additional quota from the start?

@brennen, To avoid the appearance of "Umbrella" projects with a broad scope, such as all the work to be done by an engineering team or a large problem space. (1) that having "releng" in the project name might invoke would y'all be ok with calling the project something like "devel-stats" as a riff on https://www.mediawiki.org/wiki/Development_statistics?

T351253#9332725 helps me understand what is happening, and broadly why. Now the question is how should we adjust either CMV or the conventions used in the function-orchestrator repo to get back to a place where the linter can be used?

In T351253#9332578, @Jdforrester-WMF wrote:

Here's the MR for which we had to disable CMV in the repo: https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/85

@Jdforrester-WMF Do you have some examples of this happening that I can take a look at in GitLab? I did not see this issue when testing commit messages like https://gitlab.wikimedia.org/bd808/cmv-mr-test/-/commit/7b6aa1d7c70383847eafb7abd82cb7d00f7a5f8a.

@bd808: By any chance, do you remember anything related to this setup? Asking as you seem to have been involved in setting up these mirroring URIs.

This appears to be a form of https://owasp.org/Top10/A01_2021-Broken_Access_Control/ caused by an insecure direct object reference embedded in the URL. I do not see any strong signs of attempts to implement access control in the https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/bitu/+/refs/heads/master/src/bitu/keymanagement/ source. The list view does as demonstrated limit the enumeration to the current user's records, but the other views do not seem to have any active user related access control at all.

In case it helps with debugging, the key I am expecting to see is ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK2CmBUwGc7Npo6HiEzgJemSLEKUndpRlL24I9dtkYrP bd808+wmcs@wmf-bd808-mbp02.local.