[09:52:55] !log taavi@tools-sgebastion-11 tools.wikibugs toolforge jobs restart redis2irc [09:52:58] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [15:13:18] can any of you confirm if the recent toolforge changes affected FlickreviewR 2 on commons? [15:26:05] stemoc: the timing (14 Feb) coincides with the Grid Engine brownout, but I cannot find anything on https://grid-deprecation.toolforge.org/ related to flickr or yifeibot. [15:26:50] (not sure if brownout is the right term to use -- every job that did not have someone shouting "I'm working on it" was disabled to make sure alarm bells started ringing before the grid is completely shut down) [15:27:59] some developer hates valentines day.. :P [15:29:58] runner of the bot has been inactive for a year now, maybe someone else can carry it thru? AntiComposite? [15:32:01] the yifeibot tool account has several maintainers, see https://toolsadmin.wikimedia.org/tools/id/yifeibot . I'm not sure if any of them are still active. Otherwise someone can fork the bot and keep it running that way. [15:36:50] https://phabricator.wikimedia.org/T320198 suggests everything has already been migrated though, so the 14 feb date might just be a coincidence. [15:37:43] and flickrreviewer seems to be running, https://k8s-status.toolforge.org/namespaces/tool-yifeibot/pods/flr-6d74b958d9-b28dz/ [15:37:46] a year ago.. odd its offlien tho [15:39:06] I don't have sufficient access to see if there's anything in the log files of the bot unfortunately [15:42:43] there's nothing in the logs after normal-looking entries on 2024-02-14 14:09:57. I can try restarting it, but that's pretty much the only thing I can do [15:44:05] !log taavi@tools-sgebastion-11 tools.yifeibot after reports of FlickreviewR 2 not working on IRC [15:44:08] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.yifeibot/SAL [15:44:16] !log taavi@tools-sgebastion-11 tools.yifeibot 'kubectl delete pod flr-6d74b958d9-b28dz' after reports of FlickreviewR 2 not working on IRC [15:44:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.yifeibot/SAL [15:44:52] that seems to have done something per https://commons.wikimedia.org/wiki/Special:Contributions/FlickreviewR_2 [15:44:53] just what it needed apparently. [15:45:10] might have been............constipated. [15:45:43] was all backed up [15:46:01] hopefully will review the 13k+ images without breaking again.. [15:53:40] @bd808 I'm around in case you want to discuss anything wikibugs related [15:54:42] (I'm really happy that you're picking it up to bring it into the 2020s, I don't really have much time for wikimedia stuff anymore) [15:56:09] valhallasw: I just pushed a patch to gerrit that gets rid of the last screen scraping. [15:56:52] hmmm... some rebase warning for it though... [15:56:55] I'll fire up pycharm [15:57:28] That might be my fault, I pushed a change to changeset 1004317 [15:59:08] ah. yeah. I'm seeing your review notes now too. (I had the last patch written last night but just pushed it) [16:00:27] The anchors thing is interesting in that I don't know if we can really tell what the "last" one is without screen scraping. All transactions have ids, but not all transaction ids are anchors I guess. [16:01:53] In some sense I'd argue that checking for the existence of an html tag with the correct id is almost not screen scraping, but interfacing with the "html api" [16:03:03] correct name* [16:03:34] I don't think I would disagree. That use case is HTML oriented for sure. doing it with the api data should still be possible, but it will involve more reverse engineering of phorge internals [16:06:33] https://html.spec.whatwg.org/multipage/browsing-the-web.html#find-a-potential-indicated-element -- this took way too much effort to find, but apparently `id` is the primary lookup and `name` is the fallback [16:37:04] bd808: re: tests: it would be relatively easy to *just* convert the tests to using env vars, either by storing the entire config.json in an env var, or explicitly storing PHAB_USER and PHAB_CERT and overriding those. I have no clue how to get secrets into the CI setup though :-) [16:46:38] valhallasw: It will be a lot easier to do the test envvars on the gitlab CI setup. It is possible with Jenkins, but harder to scope to a single project's tests. [17:28:15] *nod* did a quick browse through how GitLab handles it, that seems easy enough indeed. I thought maybe our Jenkins setup had some sort of CircleCI (/ one of the other old github ones) style ("encrypt your secret with this public key and then store the encrypted value in your repo") secrets handling [19:37:20] bd808: do you mind if I play around with moving the repo to gitlab? [19:38:25] valhallasw: no, not at all. I'm going to keep poking at things looking for a heuristic for the anchor selection for now. [20:08:33] https://gitlab.wikimedia.org/toolforge-repos/wikibugs2/-/pipelines that was easier than expected [20:55:28] bd808: completely hacked my way into a envvar based setup, but seems to work > https://gitlab.wikimedia.org/toolforge-repos/wikibugs2/-/jobs/210516 [20:55:53] I'm now using an envvar WIKIBUGS_ENV_CONFIG=1 to switch between config file based or envvar based config, using all the same keys [20:56:15] and with that, it's time for bed! *waves* [20:58:33] (I need to read up on how gitlab thinks about forks, merge requests and CI stuff I think...) [20:58:51] neat! I'm guessing you don't want to keep that repo state in the long term based on the commit messages you used. ;) [21:00:11] No, this is my main gripe with files-in-git-based-CI workflows... testing them is a bit of a pain :D. So yes, needs some cleanup after it works, then we can move over cleanly [21:01:15] You probably could have done it in a feature branch and ultimately rebase + force pushed the intermediate states away [21:04:00] Possibly, yes. There's no branch filters so I guess that would work, although I think some of the env vars are only available on "protected branches" which is only main in this case... I think? GitLab quadrupled the amount of possible configuration options since I last used it, and it's all _just_ different enough from GitHub (which I use at work on a daily basis) to make my head hurt :-( [21:04:41] Anyhow, feel free to force push my changes away / reimplement stuff entirely differently / etc - I'm just happy I got _something_ to work :D [21:05:19] heh. I'm getting better and better with gitlab. I only use github occasionally so I don't have to fight muscle memory on the open core sad clone of it.