Serpent OS Infrastructure - Live

[zoujiaqing]

On Thursday, 23 March 2023 at 16:39:17 UTC, Ikey Doherty wrote:
> So normally a post like this really isn't that interesting.
> However, our infrastructure has been written in D and is now
> live!
>
> We've had a couple of teething problems, notably libcurl on Alma
> Linux is super outdated, and hit pthread_t exhaustion when using
> `task!FN().executeInNewThread` so we switched to a thread pool 
> ...
>
> ![img](https://serpentos.com/static/img/blog/infrastructure-launched/Featured.webp)
>
> Other than that, it's rolling.
>
> Blog post: 
> https://serpentos.com/blog/2023/03/18/infrastructure-launched/
>
> **Code**
>
> Summit (dashboard): https://github.com/serpent-os/summit
> Avalanche (builder as a service): 
> https://github.com/serpent-os/avalanche
> Vessel (repo manager): https://github.com/serpent-os/vessel
> Boulder (build tool): https://github.com/serpent-os/boulder
> Moss (package manager): https://github.com/serpent-os/moss
> Shared service APIS: https://github.com/serpent-os/moss-service
> Shared package APIS: https://github.com/serpent-os/libmoss
>
> Instance: https://dash.serpentos.com
>
> **Basics**
>
> The build components are paired using a REST API, public keys 
> and EdDSA JSON Web Tokens. The dashboard schedules builds using 
> a graph, fetching the git recipes and determining missing 
> builds. TLDR every missing build gets scheduled and ends up in 
> the repository's public tree.
>
> Right now we're running it at a small scale to find out various 
> teething issues, but do have plans to scale it beyond the 
> current setup. Long story short we're looking to a k8s style 
> setup with separate postgresql (rather than lmdb), and 
> transient builders rather than the current pairing system for 
> blessed instances.
>
> Also we're growing highly tired of relying on C libs that are 
> host OS dependent, and are planning a rearchitecture of the 
> core tooling around fibers (using vibe.d core APIs) which will 
> lead to more natural idioms (allowing us to kill our 
> predominantely OOP approach and move towards ducktyping and 
> significantly less allocations)

Great project!