Mon, Apr 26
I'm not entirely convinced this should be solved by Wikibugs -- isn't this better solved at the client side by ignoring bots when it comes to alerts?
Tue, Apr 13
That would be nice! Unfortunately the display name is not part of the stream-events data format:
Mar 29 2021
Mar 28 2021
Feb 28 2021
@Nikerabbit this is a bit confusing to me. My understanding of the linked news post is that
Feb 27 2021
We use a server password to login, cf. https://freenode.net/kb/answer/registration#logging-in. The login sequence looks like this:
Jan 21 2021
Oct 10 2020
Yeah, I just deleted the .err file, so there was probably some cache confused. Now that the bot has run again the .err file is there again (albeit empty).
Oct 9 2020
You're right, the .err is indeed not truncated automatically. The first messages date back to about January this year, and given the 1.5MB log file size, I think truncating by hand is probably the best approach. I just did so :-)
They are rotated nightly (see https://github.com/wikimedia/labs-tools-forrestbot/blob/master/wblogging.py). We do sometimes generate a lot of logs in one day, but that's just because we have a development community that does a lot of work ;-)
Aug 19 2020
Jul 12 2020
The suggested replacement is https://quarry.wmflabs.org/ . For example, https://quarry.wmflabs.org/query/46608 is a converted version of brokenimages for nlwiki. https://quarry.wmflabs.org/query/46611 is an alternative version that is more convenient to export as wikitable (under 'download data').
Jul 11 2020
Jul 10 2020
Thanks for fixing this so quickly, @Legoktm!
Jun 30 2020
Jun 19 2020
See discussion in T237109:
Jun 17 2020
Jun 14 2020
Jun 12 2020
Apr 28 2020
Apologies for the mess; the bot was blocked on adding a task to T249730. When it crashes, it reprocesses the entire queue -- which is supposed to be idempotent as it checks whether the requested tags are already present...
Mar 1 2020
Feb 19 2020
Feb 18 2020
Feb 12 2020
....except that I forgot to update the dependencies! Did that and restarted wb2-phab... I think that should now really fix it.
2020-02-12 12:43:01,182 - urllib3.connectionpool - DEBUG - https://phabricator.wikimedia.org:443 "POST /api/feed.query HTTP/1.1" 200 58 2020-02-12 12:43:02,311 - urllib3.connectionpool - DEBUG - https://phabricator.wikimedia.org:443 "POST /api/feed.query HTTP/1.1" 200 58 2020-02-12 12:43:03,429 - urllib3.connectionpool - DEBUG - https://phabricator.wikimedia.org:443 "POST /api/feed.query HTTP/1.1" 200 None 2020-02-12 12:43:04,547 - urllib3.connectionpool - DEBUG - https://phabricator.wikimedia.org:443 "POST /api/feed.query HTTP/1.1" 200 None 2020-02-12 12:43:05,651 - urllib3.connectionpool - DEBUG - https://phabricator.wikimedia.org:443 "POST /api/feed.query HTTP/1.1" 200 160
Feb 5 2020
Jobs restarted so this should be working now
Jobs restarted so this should be working now
I assume this should be handled equivalently to jenkins-bot and pipelinebot, i.e.: only report changes towards negative votes?
Jan 28 2020
Forgot to reopen this...
Jan 23 2020
Discussed on IRC. Made two main changes:
Jan 19 2020
From what I can see the bot crashes and restarts a few times per day, which -- although not great -- I think is acceptable. About 2/3rd of those are errors retrieving anchors, the rest are about 50-50 503s from the API and cursor errors that would have caused hangs.
python-phabricator supports tokens as well: https://github.com/disqus/python-phabricator/blob/master/phabricator/__init__.py#L378
and still uses params: https://github.com/disqus/python-phabricator/blob/master/phabricator/__init__.py#L307
Looking at the examples, a call is now supposed to be done along these lines:
Jan 15 2020
I reverted the config.py back to use certificates. I'm not entirely sure how api keys are supposed to be used in phab; should they just be passed as part of the API request, the same way the session key is passed at the moment?
Jan 14 2020
Sorry, that's an old venv that should be removed.
Jan 13 2020
The same issue also caused Gerrit-Reviewer-Bot to stop working: (see https://github.com/valhallasw/gerrit-reviewer-bot/issues/22)
Dec 31 2019
I have deployed this patchset; it needs some work (formatting etc) and the change should really go upstream to Fab; I'll discuss that with @Legoktm. For now I just want to have the code running so we have some more information on how often we get errors back from the API. Based on that we could either have somewhat extensive error handling, or just let it be handled by the crash-and-restart loop.
Dec 20 2019
First of all thank you for restarting wikibugs when this happens!
Dec 11 2019
I'm actually unsure what needs to happen for these hosts... and not really sure why I'm a maintainer. Probably needed to fix something as admin at some point :-)
Nov 23 2019
Nov 19 2019
The bot is running again -- the issue was an empty file_regexp on the configuration page and the bot crashing because of that. I'll add some extra monitoring as well as checks for the config page over the coming week, but for now at least the bot is running again.
Thanks for spotting that -- I think something has changed in the API response used to get the reviewers:
Nov 1 2019
Thanks for noticing & fixing this -- I had received a bunch of alerts, but didn't have time to look into it until tonight (and given that RTB is not super time critical I thought I would be in time -- but y'all were faster! :-)).
The bot is not being klined (we should indeed be exempt from that on a per-channel level), but being disconnected. Still problematic, but a little bit less so.
Oct 25 2019
Oct 12 2019
Ok, deployed this implementation. Let me know if you run into anymore messages that should be filtered out (or should _not_ be filtered out), if possible with the date/time (UTC) of the message; I'll then try to be quick enough to grab the relevant log file from toolforge to write a test :-)
After some more digging:
Ok, fiddled a bit with the implementation (which now only reports jenkins-bot/pipelinebot if they change their vote to something negative). This seems to work overall, and I believe it filters out most if not all the offending messages.
IRC is a bit different as it's a broadcast notification in addition to the regular email notifications. Because it's a broadcast, it's also not possible to configure it per-user (other than filtering in your IRC client).
Oct 6 2019
I've looked into gerrit stream-events log files a bit today. The only reference to Fresnel that I can find is in e.g. the first jenkins-bot comment on https://gerrit.wikimedia.org/r/540525. Is that the Fresnel we're discussing? Because (as far as I can see) those are already correctly filtered out as jenkins-bots _almost_ always sets "CR: 0" in its reviews.
Sep 29 2019
Ah, I had not realized bulk edits were a restricted group. Unfortunately, it doesn't help much...
Testing bulk action
This is intended, as we don't want untrusted users to be able to perform silent mass actions, and don't want to add the complexity of rights management or per-user configuration.
What, exactly, should be filtered out for PipelineBot and Fresnel? Anything from those users, or only if the patch is already merged...?
Sep 28 2019
Sep 17 2019
The RTB code could theoretically be changed from 'last patch merged' to 'lowest version number', or something along those lines -- but this would be a complex bit of code: currently, we add a hashtag based on the branch, and phabricator will resolve this to a tag through an alias. To support 'lowest version number', we'd need to parse all tags and somehow figure out which version they are.
Sep 7 2019
Not entirely clear to me what is happening; The log files show
Aug 29 2019
Aug 23 2019
I've extended the monitoring a bit so that I get an email when the bot fails (at least, that's the plan) so that issues like this can be resolved more quickly. I think it's not worth spending time to think of how to handle this edge case as it only rarely happens and there's an easy workaround available (creating an extra tag).
Aug 21 2019
The change has later been cherry-picked to the correct branch in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/528211/. Maybe the incorrect branch has been deleted?
Note that these changes were in AbuseFilter, not in core. Do we expect
extensions to follow the same branch naming as core, or should it be more
Aug 20 2019
Shouldn't the branch name then have been wmf/1.34.0-wmf.16 instead of wmf/1.34-wmf.16? Looking at the branch-to-slug logic:
Aug 19 2019
Aug 14 2019
Ok, then I'm going to close this ticket as this seems unrelated.
Aug 13 2019
I'm a bit confused -- are you trying to use Gerrit Patch Uploader and/or Wikimedia's Gerrit, or just testing something locally?
Jul 31 2019
Not sure what to do on this -- if the infra doesn't work there's not much to do other than erroring out.
From the error logs:
Traceback (most recent call last): File "/data/project/gerrit-patch-uploader/www/python/venv/lib/python3.4/site-packages/urllib3/connectionpool.py", line 600, in urlopen chunked=chunked) File "/data/project/gerrit-patch-uploader/www/python/venv/lib/python3.4/site-packages/urllib3/connectionpool.py", line 343, in _make_request self._validate_conn(conn) File "/data/project/gerrit-patch-uploader/www/python/venv/lib/python3.4/site-packages/urllib3/connectionpool.py", line 839, in _validate_conn conn.connect() File "/data/project/gerrit-patch-uploader/www/python/venv/lib/python3.4/site-packages/urllib3/connection.py", line 301, in connect conn = self._new_conn() File "/data/project/gerrit-patch-uploader/www/python/venv/lib/python3.4/site-packages/urllib3/connection.py", line 168, in _new_conn self, "Failed to establish a new connection: %s" % e) urllib3.exceptions.NewConnectionError: <urllib3.connection.VerifiedHTTPSConnection object at 0x7fd4ab209ba8>: Failed to establish a new connection: [Errno -2] Name or service not known
Jul 27 2019
Jul 16 2019
Jun 25 2019
Based on the experience we had with moving from compat to core, I would advice against a new repository for the continued development. I'm afraid it will lead to a slow death of v3 (with lots of people not moving, and then once they move it becomes very painful due to the large difference between the versions).
Jun 11 2019
Jun 5 2019
May 31 2019
- Wouldnt ("en", "wikipedia", "my_username", BotPassword("botpassword suffix", "bot password")) work in the password file? See LoginManager.readPassword in login.py.
- If not, that sounds like something we should support...
- I believe it is possible to pass the botpassword in the classic login process by using "prefix@password" as password (this is not clearly documented on mw.org but is shown after creating a botpassword).
May 30 2019
Ik ben even door de lijst van vannacht heengelopen; daar geen bijzonderheden gespot.
Excuus, dat had ik inderdaad niet overgenomen uit de oorspronkelijke email. Maar je hebt het gelukkig zelf gevonden.
May 29 2019
May 28 2019
Another 🥨 here to test wikibugs
May 22 2019
May 19 2019
Looking at the code: