[07:39:10] hmm, im running a php8.2 webservice, and my laravel codes is 500ing, however I dont see anything in wbeserver logs? any pointers as to where the logs might be , or do i have them turned off somewhere)? [08:01:17] addshore: how did you start your webservice? (if you give me the tool name I can check) usually logs are in uwsgi.log/err [08:05:07] I did check my webserver, ended up solving my particualr issue a different way, but still cant find my logs :P [08:05:10] tool is "wikicrowd" [08:05:37] šŸ‘€ [08:07:01] I see, the logs are in `~/access.log` (currently empty) and `~/error.log` (has some logs, but little) [08:08:01] it's using lighthttpd, and the config is merged with the `~/.lighthhtpd.conf` file you have there (just fyi) [08:09:37] hackish way to see the contents of the merged config (grepping for logs): [08:09:45] https://www.irccloud.com/pastebin/i5ScPWeG/ [08:11:22] this might be more helpful in the future too (as it does not use the random pod name that changes): [08:11:22] `tools.wikicrowd@tools-bastion-13:~$ kubectl exec -t $(kubectl get pods -l name=wikicrowd -o name) -- cat /tmp/lighttpd.conf | grep log` [08:11:47] Note that that only works for the lighttpd based services (like php8.2) [08:54:29] Great! [09:31:09] Hey all! I have a question regarding toolfroge and node.js versions. This paragraph mentions "node18" https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Latest_supported_pre-built_images and I'm wondering if I can use node20 somehow? If not, no biggie! [09:32:40] I think the build service (https://wikitech.wikimedia.org/wiki/Help:Toolforge/Building_container_images) might support more Node versions [09:32:47] (but I havenā€™t used it with Node yet) [09:47:16] here's a sample buildservice app using node (and vuejs) https://gitlab.wikimedia.org/toolforge-repos/sample-complex-app-frontend/ [09:47:59] you should be able to tweak the node version it uses with https://github.com/heroku/buildpacks-nodejs?tab=readme-ov-file#nodejs-version [10:38:36] I want to run a Vue app as a tool, built with Vite [10:38:45] I found one guide on Wikitech recommending express as the server https://wikitech.wikimedia.org/wiki/Help:Toolforge/Node.js#Deploying_a_Vue_JS_Application_using_Node_JS_and_Vite [10:39:11] but if Iā€™m not actually running any server-side JS, is there a reason why I wouldnā€™t want to just use a static server instead, like https://wikitech.wikimedia.org/wiki/Help:Toolforge/My_first_Buildpack_static_tool ? [10:39:28] (assuming I can get the build service to run `npm run build` at build time, to populate the `dist/` directory) [10:41:12] lucaswerkmeister: I think you should be able to use the static one yes, [10:41:33] it should even detect that you have a package.json and run npm run build automatically [10:41:43] nice [10:41:49] then Iā€™ll see if I get anywhere with that, thanks :) [10:49:58] youā€™re right, it seems to have run `npm run build` without even any `Procfile` [10:50:38] (but of course itā€™s not going to be able to launch anything ^^) [10:54:37] hm, the static example just hard-codes the port to 8000? can I rely on that? [10:54:52] (since the vue / express example is very adamant on using the PORT envvarā€¦) [10:56:09] also, I think https://wikitech.wikimedia.org/wiki/Help:Toolforge/My_first_Buildpack_static_tool is actually missing the ā€œcreate a Procfileā€ step? (thereā€™s a Procfile in the linked sample repo but I donā€™t see the step creating it) [11:28:43] true let me add it [11:29:26] I think that it's better to use the PROC env var (in case we ever change it), though I don't see anytime soon (years ahead) when we will want to, so kinda safe to keep 8000 if you prefer [11:55:27] !log wikidata-dev special-new-lexeme-testing: created VM (Audrey, Arthur, Lucas collaboratively) [11:55:29] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [12:02:35] !log starting toolforge builds-builder upgrade, no downtime expected though some builds might fail to start/list/log/show while the upgrade is in progress T374908 [12:02:36] dcaro: Unknown project "starting" [12:02:36] T374908: [builds-builder,builds-api] Upgrade tekton - https://phabricator.wikimedia.org/T374908 [12:02:46] !log tools starting toolforge builds-builder upgrade, no downtime expected though some builds might fail to start/list/log/show while the upgrade is in progress T374908 [12:02:49] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [12:02:51] (first facepalm xd) [12:27:13] !log tools upgrade finished, build actions have become slower than usual (T376710), running tests and investigating [12:27:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [12:27:18] T376710: [builds-builder,builds-api] After the upgrade build actions take >10s - https://phabricator.wikimedia.org/T376710 [12:38:13] !log tools tests are passing correctly, upgrade finished, will investigate the increased slowness as a followup [12:38:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [12:46:34] dcaro: yeah, I was thinking of putting the port in the Procfile (uwsgi --http-socket :$PORT?) instead of uwsgi.ini so it can use the envvar, and thatā€™s how I noticed it was missing ^^ [12:46:54] thanks for adding it! [12:47:25] np :), thanks for reporting it missing [12:48:29] I think you can use environment vars also in the uwsgi.ini (`$(ENV_VAR)` it seems, by the last note in https://uwsgi-docs.readthedocs.io/en/latest/Configuration.html#placeholders, did not test it yet) [14:06:40] !log wikidata-dev special-new-lexeme-testing: configured short URLs https://www.mediawiki.org/wiki/Manual:Short_URL/Apache [14:06:42] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-dev/SAL [14:44:02] So, is there any other tool that outputs the name of public databases? (re @wmtelegram_bot: though it probably won't do what you want due to architecture changes since 2018) [15:14:32] Yetkin: maybe https://db-names.toolforge.org/ ? [15:14:50] I found it at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database#Metadata_database but I'm not sure if that page is up to date. [15:19:20] Thanks. Any user databases to share commond datasets among developers? (re @wmtelegram_bot: Yetkin: maybe https://db-names.toolforge.org/ ?) [15:22:41] if you mean the toolsdb _p databases, you can list those with a query like this one https://quarry.wmcloud.org/query/86926 [15:23:46] (it's a bit of hack because you have to input one random db as the dbname, so that quarry selects toolsdb instead of wikireplicas as the data source) [15:29:41] Thanks for this. Is there any documentation as to what datasets are being shared on these databases? It would be good to have a page (portal) where one could view them and create new tools, if needed šŸ˜ƒ (re @wmtelegram_bot: if you mean the toolsdb _p databases, you can list those with a query like this one https://quarry.wmcloud.org/query/86...) [15:43:26] I agree it would be useful, at the moment there's no such list, as any toolforge user can create a new _p database [15:44:15] maybe it could be added as a feature to toolhub :P /cc bd808 [16:00:04] https://tool-db-usage.toolforge.org/ lists all of the schemas, but does not have any descriptions. [16:28:13] yeah tool-db-usage can be very useful, and I guess it would be easy to modify to allow filtering only schemas with _p dbs inside [16:28:42] but you can also use my quarry hack... I think adding descriptions for _p databases would be the real game changer [16:29:36] basically allowing tool owners to say "my tool runs at this address, and it also generates a public database with this name that you can query if you need " [16:30:25] that's why I was thinking of toolhub because I thought that info would fit nicely in a page like https://toolhub.wikimedia.org/tools/toolforge-view-it [16:38:27] Folks have definitely talked before about using Toolhub to document data sets that are available around the movement. We never have come to consensus on what that data would need to look like. It seems related to, but different from, the kind of data we collect in a toolinfo.json records today. [16:39:19] I feel like there have been other discussions about creating "data catalogs" in other places. [18:01:46] dcaro: you were right, $(PORT) works just fine in uwsgi.ini! https://gitlab.wikimedia.org/toolforge-repos/codex-playground/-/blob/main/uwsgi.ini?ref_type=heads [18:04:55] I added it to the wikitech page now [18:11:06] is there some sort of industry standard for open data catalogs, or is that stuff all bespoke? [18:48:26] !log lucaswerkmeister@tools-bastion-13 tools.codex-playground deployed 0dce4512b7 [18:48:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.codex-playground/SAL [22:26:06] That's a good question AntiComposite. The folks in https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering are maybe better equipped to find an answer than I am.