I would like to do some refactoring/rearranging of the code base with a goal of having the bot present as a single python program using a sub-command pattern to expose each major task (gerrit watcher, phab watcher, irc emitter, etc). I used this general pattern when creating the [[https://gitlab.wikimedia.org/toolforge-repos/gitlab-account-approval|gitlab account approval bot]] where it has proven rather nice for local testing and exposing actions to #toolforge_jobs_framework via a #toolforge_build_service managed image.
Changes envisioned:
[] Move all python code into a module (`src/wikibugs`)
[] Create a top level entrypoint at `wikibugs.__main__` so that it can be executed as `python3 -m wikibugs ...`
[] Move the entrypoint of `grrrrit.py` to `python3 -m wikibugs gerrit`
[] Move the entrypoint of `wikibugs.py` to `python3 -m wikibugs phorge` (or `python3 -m wikibugs phabricator`?)
[] Move the entrypoint of `redis2irc.py` to `python3 -m wikibugs irc`
[] Move the entrypoint of `taxonomy.py` to `python3 -m wikibugs taxonomy` (or `python3 -m wikibugs update-wiki`)
[] Move the entrypoint of `tools/update_contributors.py` to `python3 -m wikibugs update-contributors`
[] Remove `manage.py` script
[] Remove `log_to_irc.py` script
[] Remove `tools/test_tags.py` script
[] Convert config.json / configfetcher.py configuration system to envvars
[] Introduce common Python linters & black for code formatting
[] Update `k8s-jobs.yaml` for new entrypoints
Remaining blockers to #toolforge_build_service conversion:
* {T353537} or deciding that `--mount=all` and a self-managed logger pattern is fine
* {T315729} or changing how we expect to deploy channel configuration changes or direct Kubernetes API usage
* {T334587} or figure out our own trigger and {T356377} or unsupported direct API calls