Configuring a Docker Cloud for Jenkins using the Docker Plugin

Studying Jenkins Agents for the kworkflow CI

Exploring Jenkins - Part 2

It has been a while since I’ve posted about my GSoC project, and a lot has changed about it.
Since the midterm evaluation period has come to an end very recently, I will take the opportunity to share how the CI infrastructure is now and my next steps for it.

Exploring Jenkins

Applying the Jenkins as Code paradigm

My first steps of community bonding in Google Summer of Code

I’ve been accepted into GSoC program for the kworkflow project this year! My proposal is to implement a self-owned server that will host a CI pipeline in Jenkins (replacing the actual GitHub Actions pipeline) and manage data telemetry. Let’s see what I’ve done in the first two weeks.

My GSoC23 journey, which I introduced in a previous post, is almost over. It really doesn’t feel like 16 weeks have passed, but I can say that, in this period, I have learned a lot and grown as a developer.

My GSoC23 project (which I talked about in a previous post) is about implementing a feature in kw that serves as a hub for the public mailing lists archived on https://lore.kernel.org, with a focus on patch-reviewing. The feature is called kw patch-hub and I will talk about what are the lore archives and its API in a later post, but in this post, I’m going to describe the Finite-State Machine model used on this feature.

Around May, I had the opportunity of helping to introduce a Database Management System (DBMS) to a project that used a file-based database. The DBMS was SQLite3 and the project was kw. This post describes my experience.

Being a somewhat new user of Zsh - made the transition from Bash around 2 months ago - I never thought I would have to learn about its completion system or how to write my own custom completion functions so soon.

I usually have my dev system and a test machine to validate my changes for developing to the Linux kernel. I also keep my config files and use them every time for my test systems. Nevertheless, I recently had to get a different test system (but very similar), and I created a new config file based on the ones that I already had; everything worked as usual, except for this error during the boot:

Since January, I have been refactoring and improving the deploy code in order to make it easy to add other platforms. Introducing Raspberry Pi support was a great study case to find the weak points in the deploy and make it more generic. As a result, I finally have a PR that enables Raspberry PI deploy and modularizes the deploy code. Check it at:

When I started contributing to Linux Kernel, one of my favorite tasks for learning more about the kernel was following the public mailing list of the subsystem that I was interested in. A few months after I started contributing to the kernel, I became a maintainer and had to follow patches related to the driver that I was maintaining. A few weeks ago, I also became one of the maintainers of the display component under the amdgpu driver. Yeah… I am aware that I’m doing poor work as a maintainer, which I blame the lack of structure in my review flow. Don’t get me wrong, I was trying… for example, I set up my neomutt to help me with that, but unfortunately, I could not use it anymore due to external forces, which broke my already inefficient review process. Anyway, I’m uncomfortable about that since I want to be a better maintainer, but I realize that I need to fix my workflow.

For a long time, I’m aiming to expand kw to provide good support for non-x86 machines. As part of this effort, I enabled kw deploy to work with an ARM target system that resembles x86, and fortunately, it works really well. However, as a DIY enthusiast, I always wanted to enable kw to deploy custom kernels to Raspberry pi, but I had the following obstacles:

For a long time, I have been considering creating a blog for the kworflow project where we can have posts that are not suitable to the standard documentation. I had this desire because sometimes, when I was working on some issues, I took some time to appraise some exciting topics related to Bash or Linux kernel that was worth publicly sharing. However, I utterly want something informal and with a low overhead to maintain. After asses my options, I decided to use a straightforward Jekyll template with trivial automation associated with the main branch.