[08:30:01] !log melos@tools-sgebastion-10 tools.itwiki deletionbot restarted [08:30:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.itwiki/SAL [08:50:34] Hi all, I'm trying to migrate my tool to be built with Toolforge Build Service. My tool consists of two binaries: a webserver, and a cronjob. Can I use the same buildpack (and the same git repository) for both? If so, how should the Procfile look like, and what toolforge command should I use to start webserver and cronjob? The examples in the [08:50:34] documentation only seem to cover building a single binary. Sorry for my newbie question. [08:56:13] !log melos@tools-sgebastion-10 tools.stewardbots ./stewardbots/StewardBot/manage.sh restart # RC reader not reading RC [08:56:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [09:13:30] Sascha79: yes, that's possible. you should add both commands to the procfile with different names (usually `web` and then something else). the `buildservice` web service type will always start the with the first command listed in the procfile, and for the cronjob the --command argument given to the jobs framework will select the command name in the [09:13:30] Procfile [09:16:51] Thank you, that's super helpful! [09:17:24] Sascha79: note though that depending on the language you use you might not be able to build the two binaries without some effort (ex. dotnet) [09:27:31] !log tools deleted shutdown grid engine VMs T314664 [09:27:37] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [09:27:38] T314664: [infra] Decommission the Grid Engine infrastructure - https://phabricator.wikimedia.org/T314664 [10:14:08] !log taavi@tools-bastion-12 tools.wikibugs toolforge jobs restart irc [10:14:11] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [10:31:48] Another build service question: How to run unit tests during the build? I've noticed that "toolforge build start https://github.com/brawer/wikidata-qrank" will happily build an image even when the head revision of my git repo is breaking its unit tests. This is not a huge issue right now, but once Toolfoge has fully automated push-to-deploy, I'd [10:31:48] obviously not want to not deploy releases with breaking unit tests. [10:41:50] !log lucaswerkmeister@tools-sgebastion-10 tools.bridgebot Double IRC messages to other bridges [10:41:53] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.bridgebot/SAL [10:44:00] !status x [10:45:25] there used to be a bot that could refresh the `Status:` in the topic of this channel? [10:48:07] Sascha79: someone else might correct me, but I suspect that’s not possible yet – as I understand it, buildpacks are intentionally limited about what you can do at build time, so I wouldn’t expect “run arbitrary test commands” to be supported [10:48:26] and if “run *specific, well-known* test commands (e.g. npm test)” was supported, you probably would’ve noticed it already [10:48:52] "go test ./..." (the standard command for golang) would be enough [10:48:57] I agree it should be part of push-to-deploy, but I’d expect it to happen outside the build – that GitLab runs tests first and then builds and deploys a new image if they succeed [10:49:06] probably worth a phabricator task in any case [10:49:25] *looks if there already is one* [10:49:35] i would agree that's not really in-scope for the build service. [10:54:16] !log melos@tools-sgebastion-10 tools.itwiki toolforge-jobs restart itwiki-orphanizerbot [10:54:18] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.itwiki/SAL [11:00:23] I left a comment in https://phabricator.wikimedia.org/T334587 that hopefully makes sense [11:05:24] I filed a feature request in https://phabricator.wikimedia.org/T360295 [11:08:56] 👍 [11:12:28] arturo: I do find some examples of using "!status" in the logs for this channel, not sure why it didn't work this time [11:13:39] 🤷 [11:23:42] !log tools point tools-static proxy to tools-static-15 (bookworm) T311913 [11:23:45] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [11:23:46] T311913: Upgrade Toolforge static server (tools-static.wmflabs.org) to Debian Bullseye - https://phabricator.wikimedia.org/T311913 [13:13:18] !log tools restart harbor services after docker service restart [13:13:22] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [14:46:15] !status Ok [14:48:01] arturo: wmopbot is the bot that does the !status trick. I don't actually remember what authn/authz it uses to decide who to listen to. [14:50:42] Looks likely that it is tied to the channel permissions. We can probably do some tuning here. bstorm and balloons both have rights that arturo does not have. [15:05:42] arturo & dhinus: you both have more irc superpowers in this channel now. I believe that you should both be able to use the "!status MESSAGE" feature of wmopbot as a result (as well as moderate the channel) [15:07:01] thanks bd808 :) [15:13:56] !status ok [15:14:01] I was already :) [15:50:34] If you need me to give permissions for something let me know. I'm pretty sure I've been powers are spread around though [16:04:10] !status ok [16:05:24] !status ok [16:05:58] thanks bd808, but I don't think it was enough [16:15:56] the !status command is allowed to any user with wikimedia cloak, in any channel where wmopbot has +t flag in channel access list and the channel topic has "| [Ss]tatus: ... |" [16:22:22] ohh, maybe arturo lost the cloak [16:23:32] I never had a wikimedia cloak [16:24:17] if you want one: https://meta.wikimedia.org/wiki/IRC/Cloaks#Obtaining_a_cloak [16:37:17] danilo: Thanks for the authoritative answer. :) Is there somewhere I should have been able to find that documented already? [17:37:59] bd808: there is a documentation in https://wmopbot.toolforge.org/help (restricted to who have +o in #wikimedia-ops) [17:47:39] danilo: all it says on that page about !status is "In channels where wmopbot has +t flag this command will change the status sction in the channel topic." [17:49:40] I added now that any user with Wikimedia cloak can use the command [17:51:30] thanks! [18:45:54] Is it possible to have a wildcard web proxie? I.e. *.catalyst.wmcloud.org all routes to a k8s instance in our CloudVPS project. [18:46:58] This will save us from having to make & clean up a web proxy for each environment on catalyst [18:58:01] kindrobot: not at the moment. support for per-project subzones (e.g. allowing catalyst to use any subdomain catalyst.wmcloud.org) was added last week, and wildcard defaults in those subzones seems like a rather reasonable and not-that-complicated feature request. [18:58:56] Oh nice taavi. Should I file a phab task/feature request? [18:59:20] And is there documentation on the per-project web proxies? [19:07:21] (sorry, my IRC bouncer froze for a second for some reason) [19:07:24] yeah, please do. [19:09:38] kindrobot: no docs yet. the tl;dr is that now a given dns zone managed by designate can be configured to be used via the web proxy system in the project that owns the zone. it needs an admin to configure it since we don't currently have an easy way to do self-service TLS cert generation. [19:11:11] OK, I'd be very interested in setting that up, so that our environments don't pollute the main subdomain [19:11:53] indeed your use case seems reasonable for this system. please file a task, I'll look into it tomorrow morning [19:12:17] Is https://phabricator.wikimedia.org/project/view/474/ the best place to file both tasks? [19:12:57] yes [19:13:20] Thanks! [21:13:34] I'm trying to run a pwb script using a custom buildservice container, user-config.py I get the following error `Skipped '/workspace/user-config.py': owned by someone else.` Any idea how I can resolve this ? [21:14:09] https://gitlab.wikimedia.org/toolforge-repos/wsstats is the repo for the tool [21:29:54] Wait, during the build process, is the user running the commands as root in the container ? [21:42:30] @sohom_datta: quite likely, yes. It is most certainly not running as your tool's user. [21:46:28] You might get some ideas about how to get the auth layer setup by looking at https://gitlab.wikimedia.org/toolforge-repos/pywikibot-buildservice [22:30:39] I finally got it working :) (It's a bit jank, but I basically cat user-config.py from a different file that has the bad permissions) [22:31:08] https://gitlab.wikimedia.org/toolforge-repos/wsstats/-/blob/main/scripts/runpwb.sh?ref_type=heads [22:31:25] I should document this somewhere, else I will forget it :) [22:51:13] !log bd808@tools-sgebastion-10 tools.wikibugs-testing Update and restart irc task to pick up dc8a19e2 in MR!15 [22:51:16] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs-testing/SAL [23:08:53] !log bd808@tools-sgebastion-10 tools.wikibugs-testing Upgraded to redis==5.0.3 [23:08:56] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs-testing/SAL [23:10:54] bd808: Do you know of any tool on that is using a celery backend ? [23:11:22] link-dispenser has been a constant nightmare since the celery worker randomly looses connectivity with redis [23:12:00] I haven't been able to figure out what I am doing wrong [23:12:55] @sohom_datta: I think only whatever tool RoySmith has using it? That's the T318479 task you have commented on. [23:12:56] T318479: Intermittent redis connection timeouts in Toolforge - https://phabricator.wikimedia.org/T318479 [23:13:50] I did create T360378 today and will poke at that tomorrow if t.aavi doesn't tell me its the worst idea ever. [23:13:50] T360378: Provide a Redis container for use within a tool's namespace - https://phabricator.wikimedia.org/T360378 [23:15:43] I don't think anyone ever really considered the shared Redis being used for async task queuing. It was more intended to be a cache for expensive computations [23:17:56] bd808: hmm. does the build service allow creating an image consisting purely of some apt packages? or would you also need some language runtime in a buildservice-managed redis image? [23:19:04] (if yes, I'm wondering if someone registering tools.redis or similar and publishing a redis image for everyone to use would be better than a toollabs-images.git managed image) [23:19:09] taavi: in a buildservice managed one you need something else too because the Apt pack is only an "add-on". I used Python in the https://gitlab.wikimedia.org/toolforge-repos/wikibugs2-znc image (which was needed for templating stuff anyway) [23:19:52] I could make one via build-service but it will be a heavier image than just using the stuff we make the shared images with [23:20:18] gotcha. in that case a prebuilt image sounds somewhat reasonable. [23:20:25] The Apt build pack is pretty janky too, but that's a separate issue [23:21:08] yep [23:22:17] also, if you're poking around wikibugs today, mind giving tools-bastion-12.tools.eqiad1.wikimedia.cloud a go and testing it works as expected and isn't missing any packages you expect to be there? [23:22:35] !log bd808@tools-sgebastion-10 tools.wikibugs-testing Update and restart irc task to pick up 3917e973 in MR!15 [23:22:38] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs-testing/SAL [23:23:28] taavi: I'm about to stop for the day, but I'll try the new bastion when I pick things back up. :) [23:24:26] taavi: first thing: "bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory" [23:25:35] ugh. that's not the first weird locale issue I've seen in the last week [23:26:30] !log bd808@tools-bastion-12 tools.wikibugs-testing Rolling back to dc8a19e2 [23:26:32] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs-testing/SAL