[03:33:29] 1m [07:33:28] !log paws reboot node-2 [07:33:30] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Paws/SAL [08:03:01] !log tools truncate haproxy.log to 1G (out of space) on haproxy-8 [08:03:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [08:11:58] Gouvernathor: you can always use the uwsgi python one (see https://gitlab.wikimedia.org/toolforge-repos/sample-static-buildpack-app), it will only be installed at `toolforge build` time, and that will not run during `npm ci`. There's also the possibility of using apt packages (so you can install nginx/lighttpd/anything in apt), though there's no example of a static app using those, see [08:11:58] https://wikitech.wikimedia.org/wiki/Help:Toolforge/Building_container_images#Installing_Apt_packages, might require some custom configuration though to run inside the container, depending on the webserver you install [08:28:37] Gouvernathor: you can also look at the setup I have in https://github.com/dhinus/wikidata-painters (it builds assets with npm build, then serves them using fastify/static) [11:49:11] Can someone check on puppet on the UTRS projects please? I needed to intervene to restore service this morning. [11:49:29] specifically production and database [11:57:29] AmandaNP: i whacked puppet there earlier today [11:59:25] Ahh yes, I see the last runs are fine. Just put the dots together when I saw the email. Thank you. [12:21:36] dhinus that's just the same thing I'm doing, but replacing express with fastify, isn't it ? [12:23:29] or I'm missing something [12:24:08] dcaro that's interesting [12:30:30] (if switching from express to fastify is a good thing in and of itself, for instance to lessen the server load on toolforge, I can do it, but it doesn't solve the issue I wanted to avoid, which is that it would be installed even in contexts where I don't need it, like git Pages) [12:35:15] Gouvernathor: haven't checked your repo, if you're building the assets during "toolforge build", then yes. fastify should be more performant than express, but I haven't found specific benchmarks. [12:36:32] how do static files get served in git pages? [12:37:40] (I assume you mean github pages, or is "git pages" referring to something else?) [12:40:29] it's the same thing but using Codeberg rather than Github [12:40:40] Gitlab Pages is better than Github, too [12:40:59] and *only* static files get served in git pages [12:41:38] I see. do you have a CI pipeline in codeberg that generates the static files? [12:41:44] yep [12:41:50] my app uses Angular [12:42:17] so the CI runs the angular build command, and gives the location of the built files to the pages action [12:42:42] https://codeberg.org/Gouvernathor/ParliamentDiagram-Angular/src/branch/main/.forgejo/workflows/publish-pages.yml [12:42:44] gotcha. probably what dcaro was suggesting could be the cleanest route in toolforge, but it's a bit hacky to configure [12:43:07] in the future, we could consider adding a buildpack like https://github.com/heroku/buildpacks-frontend-web [12:44:10] that looks great [12:44:42] so effectively the server architecture would be included in the heroku thing rather than an express/fastify dependency [12:44:56] and already available on the serve [12:45:02] yes, basically it would be included in the generated container image [12:45:02] the Toolforge server [12:45:09] hmm [12:46:15] I think it would be great to provide a batteries-included way to just serve a static website, for instance the Pages action of github or codeberg : they can change the implementation as they want depending on what suits their needs better [12:47:03] I just have the charge of building it and passing the directory for the built files [12:48:05] if I understand what github/codeberg do, they have an API where your CI can push static files to deploy [12:48:27] yep [12:48:39] and they decide how to serve them [12:48:47] we could implement something similar, but I think that the buildpack above would achieve a similar result without the need to configure a CI [12:49:11] well in my view yes that would be doing pretty much the same thing [12:49:24] it would build the files as part of "toolforge build", based on some standard config (e.g. "npm run build") [12:50:09] I think we need a phab task to discuss this, would you mind creating one? it can be generically about "deploying static apps to toolforge" [12:50:13] instead of writing it in a yml file, I put it in package.json, but it's the same thing [12:50:15] yup [13:08:06] https://phabricator.wikimedia.org/T435088 [13:08:18] dhinus [13:08:36] Gouvernathor: thanks! [13:14:29] if the only need is to deploy static files to a domain name, you can host with GitHub pages, CloudFlare Pages, Netlify, and so many other services… you don’t have to use toolforge for it. [13:25:42] sure, and I already do that, but the goal is also to replace an existing tool, and so to reuse the same domain name in the end [16:00:48] Gouvernathor: as of right now, we support deploying webservices on push :), in case you are interested (docs: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Deploy_your_tool#Triggering_a_deployment_from_your_CI_runner and example: https://gitlab.wikimedia.org/toolforge-repos/wm-lol) [16:22:28] dcaro: where do I find wm-lol’s components config? [16:22:39] is it not checked into git? [16:23:18] lucaswerkmeister: https://gitlab.wikimedia.org/toolforge-repos/wm-lol/-/blob/main/config.yaml?ref_type=heads [16:24:30] the docs are not updated yet though xd [16:24:38] (the toolforge docs) [16:33:17] ah, thanks [16:33:23] yeah hence me looking for the yaml instead :P [17:08:02] !log lucaswerkmeister@tools-bastion-15 tools.lexeme-forms deployed b6485e5984 (l10n updates: el, fa, fi, ga, gl, ja, lb, ms, nb, sl, tr – a few had queued up due to T432838) [actually deployed bb18af2eb1, temporary T431146 branch rebased on top of that] [17:08:08] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [17:11:14] Hi! I migrated the Paulina tool to the new build service container, and started the webservice with --mount=none, to disable NFS mounts. [17:11:15] The container status is ok. However, the tool runs slower than with the legacy system, and after some time, it starts giving this error: [17:11:16] Wikimedia Toolforge Error [17:11:18] The tool you are trying to access is currently receiving more traffic than it can handle. Please try again later. [17:11:19] If this issue persists, you may wish to notify the tool's maintainers about the error. [17:11:21] Do you know any step I can do to optimize the container? [17:11:22] For context, this is the whole Phabricator issue: https://phabricator.wikimedia.org/T432878 [17:14:57] `toolforge components` potential bug: in quickcategories tool, `toolforge components config generate` reports “Warning: Job background-runner seems not to be a build-service based job (or no build found for it), skipping” even though it is buildservice based (and the build exists AFAICT) [17:20:13] dcaro I could be interested, if it was possible to trigger the deploy on updates of one repo but pull another, and also to pass env variables to the build phase :) [17:20:40] but I don't actually need it, the legacy tool doesn't get automatic updates and it wasn't that big a deal [17:44:22] interesting, `toolforge components config delete` doesn’t delete the corresponding kubernetes deployments? [17:44:41] (for me that’s fine because I was just gonna recreate the config with a different branch name in the source_url anyway, I’m just surprised ^^) [17:45:00] !log lucaswerkmeister@tools-bastion-15 tools.quickcategories deployed fe67524e52 (migrate to Toolforge Components Service for webservice and backround runner) [17:45:02] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [17:45:05] ^ woooooooh [17:52:42] dcaro: I tried setting up push-to-deploy but GitLab didn’t like the resulting CI config :< [17:52:49] https://gitlab.wikimedia.org/toolforge-repos/quickcategories/-/pipelines/218891 – “image is defined in top-level and `default:` entry” [17:53:21] does that sound like a bug worth reporting (can the deploy-to-toolforge.yaml file be written differently to avoid this error?), or do I just need to restructure my .gitlab-ci.yml a bit to avoid it? [17:53:32] (that would probably mean copying the `image` into each of my own jobs, I guess) [17:55:11] hm, according to https://docs.gitlab.com/ci/yaml/deprecated_keywords/ globally defined image is deprecated [17:55:24] so I guess deploy-to-toolforge.yaml should move to default: [17:55:48] but also, actually, better to put the image into the two deploy jobs? so it doesn’t interfere with the rest of the CI [17:56:03] (and so the rest of the CI’s default image doesn’t override the one needed for deploy-to-toolforge.yaml!) [18:54:02] lucaswerkmeister: can you open a task for it? Might be that the ci yaml needs updating yep [18:56:07] Gouvernathor: the multirepo is supported (each component can have its own build git repo independently to the config itself, the components are deployed all at the same time, and can be triggered from anywhere, it will skip the ones without git changes unless forced to rebuild) [19:03:25] dcaro: done, https://phabricator.wikimedia.org/T435130 [19:03:54] Thanks! [19:05:24] and I guess I might as well give you a merge request at this point ^^ [19:08:58] https://gitlab.wikimedia.org/repos/cloud/cicd/gitlab-ci/-/merge_requests/95/diffs [19:34:00] !log jeanfred@tools-bastion-15 tools.integraality Deploy 12202cd (Refactor: columns own their SELECT variables for drill-down queries) [19:34:02] !log jeanfred@tools-bastion-15 tools.integraality Deploy 3f69cf4 (Extract _format_value_sparql helper for value-to-SPARQL-term conversion) [19:34:03] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [19:34:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [19:34:05] !log jeanfred@tools-bastion-15 tools.integraality Deploy f9043eb (DescriptionColumn: show the description value in positive drill-down) [19:34:06] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [19:34:07] !log jeanfred@tools-bastion-15 tools.integraality Deploy 3976414 (ReferenceColumn: show statement value in negative drill-down) for T428637 [19:34:09] !log jeanfred@tools-bastion-15 tools.integraality Deploy 589a9a3 (ReferenceColumn: show reference value in positive drill-down) for T428636 [19:34:09] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [19:34:10] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [20:22:17] !log jeanfred@tools-bastion-15 tools.integraality Deploy 853a540 (Add --page argument to CLI for single-page updates) [20:22:19] !log jeanfred@tools-bastion-15 tools.integraality Deploy bbf2c99 (Set name in toolinfo record to toolforge-$TOOL_NAME to avoid duplicates) [20:22:19] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [20:22:20] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [20:22:21] !log jeanfred@tools-bastion-15 tools.integraality Deploy 1b3b5ec (Update toolinfo.json record, based on latest 1.2.2 schema) [20:22:23] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [20:32:11] Maybe off topic but if there’s a better channel/discussion group please let me know: [20:32:12] Q: does anyone know if it’s acceptable to batch create category pages on Wiki Commons for uploaded books in series? Currently they are not well organized and I think the most meaningful and feasible way is to do it is using categories. [20:37:35] Have you asked on Wikimedia Commons? (re @PhV6OSm4va3IiJ: Maybe off topic but if there’s a better channel/discussion group please let me know: [20:37:36] Q: does anyone know if it’s acceptable to ...) [21:48:00] Hey, question related to Toolhub. I (belatedly) followed the docs regarding duplicates and renamed the tool in toolinfo to add the toolforge prefix (https://github.com/JeanFred/inteGraality/commit/bbf2c995). It did not exactly go as I thought it would − the integraality (https://toolhub.wikimedia.org/tools/integraality) entry is gone, but in some ways it had better [21:48:00] metadata (an [21:48:01] notations) than the current result − and I did not make a backup/snapshot of it either. Among other things, the tool is gone from the Coolest Tool list (hashtag bragging rights 😅). How shall I best proceed? [21:50:03] (I guess I can use Toolhub-evolved as temporary backup :D https://toolhub-evolved.toolforge.org/tools/integraality (https://toolhub-evolved.toolforge.org/tools/integraality)) [23:19:59] @JeanFred: a phab task may help us figure out what can be done better than this chat. I can at least help fix the lists to point to the new "official" record. The crawled content doesn't look like it updated in the way I would have expected either so there might be something that I can adjust there.