Page MenuHomePhabricator

goodbot in Zulip lists outdated 2020 projects
Closed, ResolvedPublic

Description

@goodbot in Zulip lists projects from GSoC/Outreachy 2020 when entering the command !projects.
Applicants still enter that command and get outdated information.
Please fix this.

Event Timeline

This ticket shall not be closed until there is a process that is documented and consistently applied.™

Same for !gsoc which prints a link for this year: https://www.mediawiki.org/wiki/Google_Summer_of_Code/2021 and You have been subscribed to the #gsoc21-outreachy22 stream for further help.

The tool's maintainers (per https://toolsadmin.wikimedia.org/tools/id/goodbot) are @xSavitar, @Pavithraes, and @QEDK. Source code is at https://github.com/QEDK/goodbot.

I feel like the code for this bot should be moved to gerrit or gitlab to make it easier to collaborate on.
(<rant>generally projects like this that are intended as shared infrastructure should not end until the canonical code is somewhere other than an individual technical volunteer's personal github account.</rant>)

Pinging also @QEDK on Zulip about the issue..

The tool's maintainers (per https://toolsadmin.wikimedia.org/tools/id/goodbot) are @xSavitar, @Pavithraes, and @QEDK. Source code is at https://github.com/QEDK/goodbot.

I feel like the code for this bot should be moved to gerrit or gitlab to make it easier to collaborate on.
(<rant>generally projects like this that are intended as shared infrastructure should not end until the canonical code is somewhere other than an individual technical volunteer's personal github account.</rant>)

There are some immediate fixes we can do and some other things that are more annoying, for e.g. triggering a redeployment with updated templates will fix the immediate need we have (I am on it now), we just need someone to make and push the commits when needed. On a longer term, the issue of collaboration aside, the reason we/I have not migrated is because of how we do CI/CD, as currently we are using GitHub Webhooks and a backend server that restarts containers, using a different platform is a fundamental rework of how we would implement CI/CD so that's additional overhead.

@QEDK How about we remove the !projects and !gsoc option for now from the bot, eliminating the need to update the config file every year?

And, maybe for the migration part, @bd808 may have additional thoughts to share?

@QEDK How about we remove the !projects and !gsoc option for now from the bot, eliminating the need to update the config file every year?

Are these commands not actually used by the community? It doesn't seem like a large burden to have someone make a commit like https://github.com/QEDK/goodbot/commit/627f7e78ad7cc83a2ae9ef98402fbbd59f295c00 once a year. An alternate "wiki" approach to this might be to actually move that configuration to pages on mediawiki.org or wikitech.wikimedia.org and have the bot read (and cache) the config from there so that it could be edited without git access.

Wait... is that not basically what the parsebot.py script is already trying to do? Maybe that is not working because of the errors being raised in the job that runs every 5 minutes on Toolhub:

$ kubectl logs pod/goodbot.parsebot-1644356700-sfklb
From https://github.com/QEDK/goodbot
 * branch            master     -> FETCH_HEAD
Already up to date.
[... snip lots of pip package download logs ...]
Installing collected packages: [... snip ...]
Already up to date.
fatal: A branch named 'parsebot' already exists.
Already on 'master'
Your branch is up to date with 'origin/master'.

Unrelated, but the ircbot seems to still be configured to connect to freenode which is very unlikely to be useful today based on what I know of the state of freenode after Wikimedia and many many other FOSS projects migrated to libera.chat.

And, maybe for the migration part, @bd808 may have additional thoughts to share

On a longer term, the issue of collaboration aside, the reason we/I have not migrated is because of how we do CI/CD, as currently we are using GitHub Webhooks and a backend server that restarts containers, using a different platform is a fundamental rework of how we would implement CI/CD so that's additional overhead.

I'm not sure your CI is doing what it once did now that Travis-CI has functionally removed their free tier. It does look like you have a dependabot job running under GitHub Actions that is making a lot of pull requests that are sometimes merged. As noted above the bits where you are trying to run code on Toolforge to potentially update files and then submit them back to the repo as a pull request seem to be broken as well.

Migrating the project from @QEDK's personal GitHub account to an organization account where it is easier to add multiple maintainers would retain an ability to use GitHub actions and webhooks. Even migrating to Gerrit would allow the same once a mirror of the Gerrit repo was created on GitHub under the Wikimedia organization account (as is commonly done for Gerrit repos).

Are these commands not actually used by the community? It doesn't seem like a large burden to have someone make a commit like https://github.com/QEDK/goodbot/commit/627f7e78ad7cc83a2ae9ef98402fbbd59f295c00 once a year. An alternate "wiki" approach to this might be to actually move that configuration to pages on mediawiki.org or wikitech.wikimedia.org and have the bot read (and cache) the config from there so that it could be edited without git access.

I think we can direct folks to https://www.mediawiki.org/wiki/Outreach_programs, from where they can navigate to the ongoing program pages. Also, it seems we are hard coding projects in the current setup: https://github.com/QEDK/goodbot/blob/master/templates/projects.json requiring frequent updating. As with other resources, it would be nice to stick to the same approach in the case of our programs IMO.

Are these commands not actually used by the community? It doesn't seem like a large burden to have someone make a commit like https://github.com/QEDK/goodbot/commit/627f7e78ad7cc83a2ae9ef98402fbbd59f295c00 once a year. An alternate "wiki" approach to this might be to actually move that configuration to pages on mediawiki.org or wikitech.wikimedia.org and have the bot read (and cache) the config from there so that it could be edited without git access.

I think we can direct folks to https://www.mediawiki.org/wiki/Outreach_programs, from where they can navigate to the ongoing program pages. Also, it seems we are hard coding projects in the current setup: https://github.com/QEDK/goodbot/blob/master/templates/projects.json requiring frequent updating. As with other resources, it would be nice to stick to the same approach in the case of our programs IMO.

Agreed yes, as a first course of action I'll remove / refactor it to display an on-wiki link. Going through projects at a glance seems to be a decent feature, but going through each is a bit disruptive from my observation, updating it is the hassle (parsebot.py)

Migrating the project from @QEDK's personal GitHub account to an organization account where it is easier to add multiple maintainers would retain an ability to use GitHub actions and webhooks. Even migrating to Gerrit would allow the same once a mirror of the Gerrit repo was created on GitHub under the Wikimedia organization account (as is commonly done for Gerrit repos).

I would prefer it to be collaborative as well rather than a one-man pitstop. I am of course open to move it to the Wikimedia GitHub repo (that's a one-click thing) and Gerrit (if anyone can help me with it) That should work, I hope! 😄

Just updated the bot so older projects don't show anymore and rather just link to newest project pages. If we remove the parsing aspect of the bot, it should be simple enough to update 1 link semi-annually (Outreachy winter), and 2 links annually (Outreachy summer + GSoC)

Regarding CI, Travis only used to run tests, then GitHub fired off a check suite webhook event once they passed/failed. CD will continue to work, just needed to change the event type to all pushes to the repo instead.

I can confirm that this issue is fixed now. Thanks @QEDK for fixing it.