From b267b076b33d3ac4eb83baa32eb341c60bd8c3c4 Mon Sep 17 00:00:00 2001 From: Chewing_Bever Date: Thu, 29 Dec 2022 18:49:33 +0100 Subject: [PATCH] vieter-0.5.0: started release post --- content/posts/vieter-0.5.0/index.md | 99 +++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 content/posts/vieter-0.5.0/index.md diff --git a/content/posts/vieter-0.5.0/index.md b/content/posts/vieter-0.5.0/index.md new file mode 100644 index 0000000..73a7510 --- /dev/null +++ b/content/posts/vieter-0.5.0/index.md @@ -0,0 +1,99 @@ +--- +title: "Announcing Vieter 0.5.0" +date: 2022-12-29 +draft: true +--- + +As 2022 comes to a close, I'm ready to release another version of Vieter! + +## What's Vieter? + +As usual, a small refresher on what Vieter actually is for the new readers. +Vieter provides two main services: a Pacman repository server and a build +system for publishing Arch packages to said server. The goal is to fully +replace any need for an AUR helper, with the AUR packages being built "in the +cloud" instead. Of course, one can also publish their own packages to this +server, allowing you to create your very own customized Arch repositories! + +## What's changed? + +### Server-agent architecture + +The biggest change this version introduces is the migration to a polling-based +server-agent architecture. + +Previous versions relied on a "cron daemon". This daemon needed to be deployed +on every architecture the user wanted to build packages for, with the daemon +periodically polling the server for the list of targets to build. All +scheduling was done on the node performing the builds. + +While this system served me well for a while, it did limit possibilities for +improvement. Building on multiple servers wasn't possible, as the cron daemons +had no way of synchronizing with each other, meaning they'd all run all builds. +There was also no way for the server (or the user for that matter) to control +these daemons; they had a fixed build schedule that could only be changed by +changing a target's configuration. + +Due to these limitations, I've decided to revamp the build system & convert it +to a server-agent architecture! With this new system, the main server handles +all scheduling. On each server running builds, a "build agent" is deployed +which periodically polls the main server for new jobs. This allows a Vieter +instance to run builds on an arbitrary number of build nodes! Thanks to this, +I'm able to run 137 builds in under 40 minutes, whereas before, I needed this +time to process less than half of that :) As a bit of a stress test for my +instance, I've started replicating the EndeavourOS repository for fun. + +With the main server now being in control of scheduling, I've also been able to +implement manual scheduling of builds on the server. If a package needs to be +rebuilt, you can simply send an HTTP request (or use the accompanying CLI +command) to schedule a build job. + +### Quality-of-life improvements + +This release was mostly the build system redesign, but I've also added some QoL +improvements. Noteable additions are the option to periodically remove logs, as +an active Vieter instance can collect thousands over time. The CLI tool should +now also be a lot more stable, and will correctly display HTTP errors if +needed. There's also the option to specify what subdirectory of a Git +repository to use for a build. This is for example useful when building +packages using a Git repository [containing multiple +PKGBUILDs](https://github.com/endeavouros-team/PKGBUILDS). + +## What's to come? + +My brain never stops, so I still have a lot of cool ideas I wish to implement +in the coming months. + +For starters: better build awareness. The build system right now does not track +the progress of jobs. Once a job is dispatched to an agent, the main server +forgets about it and moves on. If a build fails due to unknown means causing +the log to never be uploaded, it'll be as if the build never happened. I'd like +to change this. I want the main server to be aware of what jobs are running, +have failed, or have perhaps timed out. This information could then be made +available through the API, providing the user with valuable insight into the +workings of their Vieter instance. + +Building on this idea, I wish to know what specific command caused the build to +fail. Was it makepkg, an HTTP error? And if it was makepkg, what error code? +can the build system respond to it by itself? The main goal is to provide a +deeper understanding into the workings of builds and the build system as a +whole. + +Another big one to tackle is API access to the repositories. These are +currently only accessible through Pacman, but having this information available +as a convenient REST API, useable from the CLI tool, sounds like a valuable +asset. This would pave the road towards repository-level configuration. + +Of course there's a lot more ideas, but the list would be too long to put here +;p + +## Conclusion + +As you can see, I still have *a lot* of ideas for Vieter. As usual however, I +can't predict when any of these features will get implemented. It all depends +on whether the uni life leaves me some time :) + +If you're interested in Vieter, considering joining +[#vieter:rustybever.be](https://matrix.to/#/#vieter:rustybever.be) on Matrix! +The source code can be found on my personal +[Gitea](https://git.rustybever.be/vieter/vieter).