Using Laminar for Self-hosted CI

Bash CI Git GNU+Linux — Published on .

I’ve hosted my own git repositories for quite a while, but I hadn’t found a simple self-hosted CI solution yet. I’ve tried several, and found them to be a bit too cumbersome to setup and actually put to use. The majority requires you to host a full “git forge”, such as GitLab or Gitea, in order to use their webhook functionality in order to trigger a CI build. This didn’t seem worth the effort to me, so I kept looking for an alternative that worked well for me.

I think I’ve finally found one in Laminar, after a suggestion from a friend on the Fediverse. I do wonder how I could’ve spent so much time searching without ever finding this solution!

Laminar itself was easy to install from source, but another person chimed in to let me know they already made an ebuild for it, which is available in their overlay, making it even easier for me to try out. A single emerge laminar, and a couple seconds of building it, and I was ready to start trying it out.

Configuration of jobs is done through scripts in whichever language you prefer, giving you quite a bit of power. The documentation seems to mostly use Bash, and that seemed to be a logical choice for me too, so that’s what I’ve been playing with as well.

Running jobs itself is as easy as laminarc queue <name>. It can’t be much simpler, and this CLI interface makes it very easy to start a new job from a git post-receive hook. I wrote one which also shows the URL of the job’s logs whenever I push new comments to the Bashtard repository.

while read old new ref
        laminarc queue bashtard \
                "GIT_BRANCH=$ref" \
                "GIT_COMMIT=$new" \
                | awk -F: '{ print ""$1"/"$2 }'

Using this, I can verify a job started, and immediately go to the page that shows the logs. I plan to use Laminar’s post-job script to leverage ntfy to send me a notification on failed builds.

Since all the worthwhile configuration for Laminar is just plain text, it is also very easy to manage in your preferred configuration management system, which is also something I plan to do in the nearby future.

One slight annoyance I have so far is that I can’t use (sub)directories for all the job scripts. Since I don’t have many yet, this isn’t a real problem yet, but it could pose a minor issue in the far future once I’ve written more job scripts.

Given that that’s the only “issue” I’ve found thus far, after a couple days of playing with it, I’d highly recommend taking a look at it if you want to set up a CI system for your self-hosted git repositories!