<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>An Oci Registry for Ci - Series - Roland's Dev Blog</title><link>https://rolandsdev.blog/series/an-oci-registry-for-ci/</link><description>An Oci Registry for Ci - Series - Roland's Dev Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sun, 18 Oct 2026 16:00:00 +0900</lastBuildDate><atom:link href="https://rolandsdev.blog/series/an-oci-registry-for-ci/" rel="self" type="application/rss+xml"/><item><title>Replacing our CI registry with Harbor on Garage</title><link>https://rolandsdev.blog/posts/replacing-our-ci-registry-with-harbor-on-garage/</link><pubDate>Sun, 18 Oct 2026 16:00:00 +0900</pubDate><author><name>rolandjitsu</name><uri>https://github.com/rolandjitsu</uri><email>rolandjitsu@gmail.com</email></author><guid>https://rolandsdev.blog/posts/replacing-our-ci-registry-with-harbor-on-garage/</guid><description><![CDATA[<p>Over the past month and a half I&rsquo;ve been rolling out a new OCI registry for our CI: <a href="https://goharbor.io" target="_blank" rel="noopener noreferrer">Harbor</a> as the registry, <a href="https://garagehq.deuxfleurs.fr" target="_blank" rel="noopener noreferrer">Garage</a> as the S3 storage behind it, on Kubernetes. It was quite the journey - a couple of incidents, a lot of measuring, and a pile of lessons about what actually limits a registry under CI load.</p>
<p>This is part 1: why we built it, the design, and the things that broke before it even carried real traffic. Part 2 will be the throughput hunt (every layer we fixed, and the surprising number that didn&rsquo;t improve). Part 3 is the storage war - including the weekend I already wrote about in <a href="https://rolandsdev.blog/posts/reclaim-deleted-disk-space-with-fstrim-in-longhorn/" rel="">the fstrim post</a>.</p>]]></description></item><item><title>Reclaim deleted disk space with fstrim in Longhorn</title><link>https://rolandsdev.blog/posts/reclaim-deleted-disk-space-with-fstrim-in-longhorn/</link><pubDate>Sat, 17 Oct 2026 17:30:00 +0900</pubDate><author><name>rolandjitsu</name><uri>https://github.com/rolandjitsu</uri><email>rolandjitsu@gmail.com</email></author><guid>https://rolandsdev.blog/posts/reclaim-deleted-disk-space-with-fstrim-in-longhorn/</guid><description><![CDATA[<p>For the past month or so I&rsquo;ve been rolling out a scalable, high-throughput OCI registry for our CI: <a href="https://goharbor.io" target="_blank" rel="noopener noreferrer">Harbor</a> as the registry, <a href="https://garagehq.deuxfleurs.fr" target="_blank" rel="noopener noreferrer">Garage</a> as the S3 storage behind it, on Kubernetes with <a href="https://longhorn.io" target="_blank" rel="noopener noreferrer">Longhorn</a> providing the volumes (that has since changed, but it&rsquo;s the setup this story happened on). That journey is worth a few posts on its own (and I plan to write them, at some point), but this one is about a single thing that caught me off guard on a Saturday morning: <strong>deleting data does not free disk space</strong>. Not on Longhorn, and not on most thin-provisioned storage - until something explicitly tells the layer below which blocks are no longer in use.</p>]]></description></item></channel></rss>