A very tiny router is provided by nanostores: https://github.com/nanostores/router

Maybe not so much for an Internet Protocol router?

Video: https://youtu.be/U7pZbCnJxEw?t=6105 (Kernel Recipes 2025 - Day 2)

Very useful. For configparser.ConfigParser I've found https://stackoverflow.com/a/57307141

Nice, it has landed. Now I'm getting:

> warning: Could not set up terminal for $TERM 'xterm-ghostty'. Falling back to hardcoded xterm-256color values

How could this happen? We're storing deploy credentials in GitHub, and configure fully automated deploy pipelines using YAML and Shell. Escaping 101. xD

https://xkcd.com/1638/

They're self-hosting at https://gitlab.wikimedia.org/explore

> other CI systems also have this problem, but often provide mechanisms to write individual tasks in other languages

GitLab CI allows to run a bunch of commands in any Docker image you specify. The Docker image and/or your scripts may be self-written.

How do you find, for instance, GitHub Actions more advanced?

> How do you find, for instance, GitHub Actions more advanced?

Being able to easily tap into an ecosystem of existing re-usable functionality (actions) is a great and pretty advanced feature that requires a very different (and more advanced) set of abstractions than running “a bunch of commands in a docker image you specify”.

Not that it’s a perfect system, but a core CI system with a decoupled layer of “things that run on that CI system” is a great model.

For example, the core of GitHub actions doesn’t have anything built-in that clones repositories. That’s a first-party action (component) that GitHub develops, releases and evolves independently. But you can roll your own if you want.

Not sure if you're aware, but Gitlab has had cross-project 'includes' for a long time, and publishes a big chunk of templates for these on gitlab.com.

They've also introduced Components a year?(don't hold me to that) ago, which is more akin to the GitHub actions model.

https://docs.gitlab.com/ee/ci/components/index.html

While components look great (and I wasn’t aware!), it’s still just the same old “template-metaprogramming-with-yaml” that includes are:

> Avoid using global keywords in a component. Using these keywords in a component affects all jobs in a pipeline, including jobs directly defined in the main .gitlab-ci.yml or in other included components.

This is very different (and a whole lot less advanced) than being able to run a 3rd party GitHub action written in JavaScript, alongside another running in its own container image, mixed in with your own steps.

Because Gitlab CI bakes everything into one layer it’s much much harder to evolve and extend, and so it fossilizes whilst being unable to shake it’s baggage.

Have you tried Gitea Actions? https://docs.gitea.com/usage/actions/overview

I have not, just read that it's a bit fresh at this point. I've not yet invested anything in my GitLab setup and will try Gitea actions before deciding. Are you running Gitea locally? How was it for you so far? Thanks

> "Gitea Actions is still under development, so there may be some bugs and missing features. And breaking changes may be made before it's stable (v1.20 or later)."