After writing about Sponsorware back in march I finally found a first project to publish following this model.

I wanted to set up some form of personal continuous integration system (or CI for short) for a while already. If you are running something that is public and open source, there are plenty of ways in achieving this, like Github Actions or Travis. Even the CI system that I finally settled on is offering a SaaS that is free of charge for Open Source projects. But what if the code of the project where you want to implement CI should not be publicly published to the web, like for example for some small home automation project? Or what if your CI pipeline would need to interact with personal access tokens or other secrets, but you are hesitant of sharing these with an external service? This is where self hosting comes into play. So last week a set a few hours of evening time on my computer apart to research options and implement a solution that works at least for me.

The often recommended solutions when it comes to CI are either Gitlab, which is a beast that comes with way more features than just CI, and Jenkins which due to its Java base cannot be considered lightweight either. On top of that we are already using Jenkins at my place of work, and its Jenkinsfile syntax just feels strange to me and using third party plugins additionally always feel like quite a struggle (but luckily I don’t have to do it).

My git repositories are already hosted in a Gitea instance that I have running on Cloudron and to benefit from automatic backups and SSL at least the management part of my CI should be running there as well. And looking at CI systems supported at looking which CI systems are supported by Gitea I ended up at Drone. Drone is written in Golang, supports a database for persistent data storage and follows a container based approach, when it comes to build environments. It comes in two parts a “server” component (which should be hosted, where it can be reached by both Gitea and the user) and a “runner” (sometimes also called “agent”) which can run anywhere where it can connect to server part, which could be anything from your workstation, a laptop, an actual 24/7 running server or a Raspberry Pi.

It took a bit of fiddling and studying the Dockerfiles published by Drone to figure out how to properly run it in the context of a Cloudron app, but the end result was a small app that is accompanied with a Makefile for easier setup and a bash script to easily run the runner on any system that can run Docker and docker-compose. For my use case it seems to be doing exactly what I wanted it to do and this blog post was for example published through it.

But to see how to better improve the app, I have decided against directly publishing it. Instead I will only publish it to those that are sponsoring my work through Github. From this I am hoping to achieve both to keep my motivation high to further improving it and users more invested in using it and providing feedback. Once I have reached my Github funding goal of 150$ per month I will make the app freely available for everyone.

I am curious how this experiment will turn out and want to thank everyone out there is supporting work in Open Source software.