// The Jenkins at home

Here's a cool animation effect I added

I would also like to share the details of the new OrangeFox CI integration in the FoxBox.

The "normal" way to build AOSP (recoveries are derivatives of AOSP) is that you have a very huge AOSP sources directory (300–400 GB). You also have your device, vendor, and kernel trees, and that's how you build it.

However, there are three main problems:

- Trees – All of them have to be very strictly maintained. Each tree should not export modules (kernels love to export modules) that are already being exported. That means you have to split such trees into common trees, and nobody likes to do that.

- Even if you do it and split the trees, updating things becomes very tedious, as each change in a common tree would affect every single tree that uses it.

- It's rather insecure because the tree of a completely unrelated device can actually copy/build/link anything to all other devices.

- Managing trees is already a hassle. Big projects use something called roomservice, which pulls trees from their Gerrit/git, checks for dependencies, and recursively pulls them as well. It does require manual intervention for even the smallest things, for example, when you want to change the branch, or when one of the thousands of repos moves or becomes unavailable.

My implementation utilizes immutable builds, which means that every single build is not influenced by any other, nor other trees and configurations.

How does it work?

I've made a service called FoxWorker, which pulls from FoxAPI for new tasks, creates podman containers that have read-only access to the OrangeFox sources, and copies the sources to a temporary location. It then pulls the device tree and checks for a file called fox_factory.json, which has the following structure (see the picture). This serves as a kind of build recipe for FoxWorker to execute, it pulls the repositories accordingly and initializes the build.

Specifically, I want to talk about two things:

1. Copying the whole sources (again, it's ~350 GB of very small files):
Now, this would be complete nonsense with a traditional file system. But since I've been using Btrfs for over 5 years, which has a copy-on-write (CoW) feature, that allows the file system to copy only the metadata instead of the actual data. On my machine, copying the entire sources directory takes about 20 seconds.

2. Podman containers:
That's yet another technology I've used for over 5 years, and it's how I host every single service of mine. It works even better for build jobs. By default, Podman uses rootless daemons which, as is obvious from the name, run the daemon without root privileges, resulting in increased security. Podman also integrates pretty well with SELinux-enabled hosts, which I always use as well.

Visually, I also want to share, that my vision of the design, is that it has to be stupidly plain, yet playful.

The main question I've always asked myself is how can I make my thing as less cognitive complex as it could even be?

The answer is not to overcomplicate the product, but to highlight the most important elements wisely.

Today, instead of new websites, I've assembled a bed.

My new room as I've moved ^^

Today - animations, optimizations and folders support

Hey Nerds!
I won a battle with Ansible and GitLab CI, so the foxwiki is finally deployed!
Take a look - https://foxwiki.orangefox.tech/