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 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/wikibugs2)
- Create a top level entrypoint at wikibugs2.__main__ so that it can be executed as python3 -m wikibugs2 ...
- Move the entrypoint of grrrrit.py to python3 -m wikibugs2 gerrit
- Move the entrypoint of wikibugs.py to python3 -m wikibugs2 phorge
- Move the entrypoint of redis2irc.py to python3 -m wikibugs2 irc
- Move the entrypoint of tools/update_contributors.py to python3 -m wikibugs2 update-credits
- 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
- Convert gerrit ssh key to envvar setting
- Introduce common Python linters & black for code formatting
- Update k8s-jobs.yaml for new entrypoints
Remaining blockers to Toolforge Build Service conversion:
- T353537: [jobs-cli,jobs-api] Allow using file logs with build service images or deciding that --mount=all and a self-managed logger pattern is fine
- T315729: Make it possible to start/restart jobs from other k8s jobs or changing how we expect to deploy channel configuration changes or direct Kubernetes API usage
- T334587: [builds-api] Add triggering support or figure out our own trigger and T356377: [toolforge] simplify calling the different toolforge apis from within the containers or unsupported direct API calls