My apologies if this ticket comes as a surprise to you. In order to ensure WMCS can provide a stable, secure and supported platform, it’s important we migrate away from GridEngine. I want to assure you that while it is WMCS’s intention to shutdown GridEngine as outlined in the blog post https://techblog.wikimedia.org/2022/03/14/toolforge-and-grid-engine/, a shutdown date for GridEngine has not yet been set. The goal of the migration is to migrate as many tools as possible onto kubernetes and ensure as smooth a transition as possible for everyone. Once the majority of tools have migrated, discussion on a shutdown date is more appropriate. See T314664: [infra] Decommission the Grid Engine infrastructure.

As noted in https://techblog.wikimedia.org/2022/03/16/toolforge-gridengine-debian-10-buster-migration/ some use cases are already supported by kubernetes and should be migrated. If your tool can migrate, please do plan a migration. Reach out if you need help or find you are blocked by missing features. Most of all, WMCS is here to support you.

However, it’s possible your tool needs a mixed runtime environment or some other features that aren't yet present in https://techblog.wikimedia.org/2022/03/18/toolforge-jobs-framework/. We’d love to hear of this or any other blocking issues so we can work with you once a migration path is ready. Thanks for your hard work as volunteers and help in this migration!

@RhinosF1 changed the task status from Stalled to Open.

The task I blocked on did resolve, but unfortunately it resolved in a way that is not immediately usable for this tool. The new system documented at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Running_Pywikibot_scripts should work great for Wikimedia SUL wikis, but it will not work for officewiki. I think I can see how to fork https://gitlab.wikimedia.org/toolforge-repos/pywikibot-buildservice to make a variant that will work for running this officewiki bot however. The changes I need should be mostly confined to changing https://gitlab.wikimedia.org/toolforge-repos/pywikibot-buildservice/-/blob/toolforge/user-config.py.

Something like this should work for Officewikibot:

# https://www.mediawiki.org/wiki/Manual:Pywikibot/BotPasswords
import os

family_files['officewiki'] = 'https://office.wikimedia.org/'
family = 'officewiki'
mylang = 'officewiki'
usernames['officewiki']['*'] = os.environ.get('PWB_USERNAME')
password_file = 'user-password.py'

# https://www.mediawiki.org/wiki/Manual:Pywikibot/BotPasswords
import os

('officewiki', os.environ.get('PWB_USERNAME'), BotPassword(os.environ.get('PWB_BOTPASSWORDNAME'), os.environ.get('PWB_BOTPASSWORD')))

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

Currently trying to figure out why this is happening:

$ webservice buildservice shell
I have no name!@shell-1700261090:~$ pwb
...
fatal: detected dubious ownership in repository at '/workspace'
To add an exception for this directory, call:

        git config --global --add safe.directory /workspace

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.)

bd808 merged https://gitlab.wikimedia.org/toolforge-repos/officewikibot-pywikibot/-/merge_requests/1

Make image work with BotPassword auth for officewiki